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

[Lennart Regebro]

On 6/14/06, Max M <maxm at mxm.dk> wrote:
> But the problem is that I don't fix bugs that doesn't exist for my
> customers. So deprecation warnings are ignored, until the product
> sponsor chooses upgrade.

Very reasonable.

> If this is how OSS generally works, as I expect, then deprecations will
> break stuff that just doesn't get fixed.

I'm not sure I follow you here.
Deprecations in themselves break nothing, of course, so I assume you
mean that the changes break stuff that doesn't get updated. This is
true, but that is true for any non-backwards-compatible change. And
every single major Zope version have had some sort of
non-backwards-compatible change. That is, in fact, the whole
definition of the major version. Otherwise it would be a bugfix. :)

> And new user will find it
> impossible to get all the products they need to work together, in the
> latest version.

This is true, and a problem. And the more modules you have the worse
it gets, as you get big compatibility matrices going on. But there is
only one answer to that, and that is to update the software. It
doens't mean *you* have to do so. But somebody has, reasonably whoever
needs the update. That's OSS. :)

Things get REALLY complex if you try to keep several version bugfree
at the same time, which I guess is one of the reasons Chris stays on
2.8 so far. He doesn't want to have two branches, one 2.8 and one 2.9
compatible, and keep them both bugfree. This is very reasonable, and
the reason for the deprecation period. The deprecation period gives
you, in effect, 18 months "notice". After 18 months, in the worst
case, the feature you used is not any longer in any supported version
of Zope. I think that's very reasonable.

-- 
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.cps-project.org/