On Wed, Jun 14, 2006 at 11:47:13AM -0400, Chris McDonough wrote: > I think that's the sanest policy. So it's OK if "bullshit" gets > called on people putting deprecation warnings into any .1, .2, etc > through .9 releases, then? This seems like the only thing that can > work. We can't expect people to upgrade to stable point releases > (e.g. 2.8.5 from 2.8.4 or earlier) just to be able to see deprecation > warnings.
That makes perfect sense to me. +1 to no new deprecation warnings in stable third-dot releases. One thing to clarify: would it be OK and even desirable to backport new deprecation warnings to the stable branch, *as long as* the deprecation period is still 1 year after the next .0 release? for example, if in the future a new deprecation warning is added in 2.11.0, with the feature to be removed in 2.13, we could add the same deprecation warning to 2.10.x bugfix releases? The advantage is that the deprecation warnings reach a wider audience of developers, giving them more lead time to fix their code. The disadvantage is that end users get more log spew about things they maybe can't fix, and that seems obnoxious to do in a stable branch. and it wouldn't make any sense at all if the deprecation requires you to replace the deprecated code with new features that don't even exist in the stable branch, e.g. because of a different Five version. OK, never mind, I think I've just convinced myself it's more trouble than help :) -- Paul Winkler http://www.slinkp.com _______________________________________________ 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 )
