On Wed, 2006-06-14 at 15:44 +0200, Wichert Akkerman wrote:
Previously Chris McDonough wrote:
A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'.
I haven't kept track of zLOG (I'm still new to this world) so I don't know if that went according to the normal schedule or not.
Actually, it will (or at least pretty close), since we aren't removing it until 2.11 (I computed 6 months based on 2.10, sorry).
If I understand this correctly the problem you are seeing is this that you develop against an unreleased Zope version, so worst case your deprecation period starts just before the first beta of release x when someone adds a deprecation and ends at the time trunk opens for development for release x+2 and the deprecated feature is removed, which can be 6 months.
No, actually, that's not what I mean.
I don't think that's a very fair method of measuring deprecation time: for stable releases which almost everyone uses the deprecation time will have been the full year.
Hmmm. Then I think someone needs to explain this: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus (Final release late June/early July 2006) vs. http://svn.zope.org/Zope/branches/Zope-2_8-branch/lib/python/OFS/Application... (fixup checkin made Nov. 4, 2005, the earliest checkin for these deprecations was Oct. 31 2005). I'm no math genius, but that sure seems like about 8 months to me end-to-end. - C