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. > Currently adding a deprecation in a release doesn't automatically equate > to a year's grace period, because people seem to assume they can > deprecate a feature in a very late point release of the current stable > branch and deprecate it exactly two releases later. Which in a > time-based cycle is always shorter than a year, because the point > release of the stable branch happens concurrently with development of > the next major release. 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. 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. Wichert. - -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )