On Wed, 2006-06-14 at 17:03 +0200, Andreas Jung wrote:
> --On 14. Juni 2006 10:59:09 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:
> > So... you're saying that 2.10 isn't going to be released until December
> > 2006, then?
> huh? The wiki says June/July...we are just running a bit late with the beta 
> releases because Philikon needed some time  for the ZPT integration..so why 
> December?

Buh.................... oh geez, let's just forget it. ;-)

> >  That would indeed make the deprecation period longer than 1
> > year, which seems to have been the intent.
> This makes no sense to me.

Let's start clean here.

What interval of time is reasonable for the period between a
to-be-removed piece of code emitting a deprecation warning and that
code's removal?

If you think 8 months is reasonable, it would make sense, for example,
that the code in OFS.Application that looks for a module-scope
'__ac_permissions__' in all products would be removed for 2.10 (as its
deprecation warning currently states).  If you think that's too short a
time, then it's broken.  Personally I think 8 months is too short a
time, and I think it should be at least one year and I think most folks
agree with this.  I don't remember what the official policy is nor would
I know where to find it.

But if you agree with this, in order to have a full year's deprecation
period, as far as I can tell, we'd need to make a policy that
deprecations can only be done in in .0 releases.  That would ensure at
least a full year between the first deprecation and the code removal.
Any other policy does not make sense if the goal is to have
full-year-long deprecation periods.

And at this point, IMO, a feature isn't really deprecated until it emits
a warning.  Older releases didn't emit deprecation warnings (partly
because there was no "warnings" module), so basically *we tried not to
deprecate anything* and we always strove (but only partially succeeeded)
at full-bore backwards compatibility, cruft-be-damned.  Things are
better now, so we can deprecate stuff, but we still need to be
consistent about how we do it.

- C

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to