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 Akkerman <[EMAIL PROTECTED]>    It is simple to make things.                   It is hard to make things simple.
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to