-----BEGIN PGP SIGNED MESSAGE-----
Chris McDonough wrote:
> 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
> 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.
+1. A deprecation is a change in the feature set, which is *not*
appropriate in third-dot releases: those releases have stability as a
primary goal; cleanliness is *not* next to godliness in that context.
> 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.
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v126.96.36.199 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -