[Zope-dev] Re: Time-based releases a good idea?

[Paul Winkler]

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