On 6/14/06, Max M <maxm@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/