[Framework-Team] Re: beta1 release timing

Martin Aspeli optilude at gmx.net
Thu Mar 8 22:30:29 UTC 2007


Wichert Akkerman wrote:

> - getToolByName gives us a lot of deprecation warnings. We can do two
>   things: undeprecate getToolByName in plone 3.0, deprecate in 3.5 and
>   remove in 4.0. Or fix all getToolByNames in 3.0. This is doable with
>   some effort.
 >
> The last one is a decision that we need to make.

I would be really careful to toe the policy line on deprecations here if 
only to toe the line. getToolByName() is *incredibly* pervasive in third 
party product code, and breaking things just because we want to get rid 
of that method is silly. This is similar to the zLOG deprecation and 
un-deprecation. The benefits of total deprecation do not outweigh the 
cost. Even if fixing it in most cases is not that hard, it's time consuming.

I would like the following:

  - Leave it now. Have it emit warnings, but preferably not duplicate 
warnings (i.e. for the same tool, or, better yet, for the same calling 
code, but that may be hard). With too many warnings, people get giant 
log files and more important log messages drown.

  - If at any point supporting the old API becomes too difficult, remove 
it. I don't see that happening very soon, though.

  - Consider some kind of compitability alias mechanism, so that when 
people keep using getToolByName(context, 'portal_types') we translate 
that to getUtility(ITypesTool), for as long as we need to (but still 
warning).

Removing in 3.5 sounds completely unrealistic to me. If we find that by 
4.0 most third party products that count (i.e. would be otherwise 
compatible) have been fixed, we can consider removal.

> It will take a couple of days for this to settle down, I'm leaving for a
> week of snowboarding tomorrow evening, so here is my proposal: we delay
> the beta a bit further to Monday, March 19. At that point I'll make a
> decision on deprecating or undeprecating getToolByName and make a
> release based on whatever product and package releases exist at that
> time.
> 
> It's a shame we have to postpone the beta further, but the CMF changes
> require some important change in our codebase that need to be finished.

But better the hit now than later. :)

Note - I can't produce any new packages by March 19th (still on holiday 
then, back on the 21st), but my packages ought to be stable for now.

Martin





More information about the Framework-Team mailing list