Previously Max M wrote:
> Andreas Jung wrote:
> >At some point you have to make a cut to get rid of old crap. Fixing the
> >issue is a straight forward approach with very little risks for the
> >programmer and it won't take too much time..I don't see a major problem
> >with that.
> Except that it hits a sore spot for open source right on the head.
> Products are developed for our customers, and they will keep working for
> those customers until they choose to upgrade.
But until then you don't upgrade and the changes made in later Zope
versions are not relevant. If and when you do an upgrade you will have
update your products to reflect that Zope (and other products)
have evolved. That will always be true for upgrades.
> If this is how OSS generally works, as I expect, then deprecations will
> break stuff that just doesn't get fixed. And new user will find it
> impossible to get all the products they need to work together, in the
> latest version.
That's a fact of life and holds for non-OSS software just as well.
> But the problem is probably not the time based release, just that there
> is to few generations for deprecations.
No matter what period we decide on it will always be too short for some
and too long for others. With the current setup the deprecation period
is a year, which seems like a decent middle ground.
Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -