-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 >> 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.
+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. - -- =================================================================== 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 iD8DBQFEkC8w+gerLs4ltQ4RAlKVAKDDTlVZj4iUT7ZZzSiN7SoCS05TfwCgjcEl Hh6RL4+6bAV4kAJPkMY1emM= =LiMJ -----END PGP SIGNATURE----- _______________________________________________ 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 )