--On 14. Juni 2006 11:24:45 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:
> 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?
The general rule for Zope 2 + 3: 1 year = 2 full major releases according the current half-yr schedule
If you think 8 months is reasonable,
I never said something like that. I even did not comment on the this issuesince I have very little insight about the internals at this point. Anything deprecated in 2.9 can officially be removed in 2.11. It should not happen that a deprecation happens after the final release.
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.
See above..I fully agree..
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.
jup
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.
A feature should never be removed if there is no reasonable replacement. A feature should only be removed if it is obviously broken and unfixable, totally out-dated and unmaintable.
Andreas -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
pgpm5d2axxsJf.pgp
Description: 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 )
