On 6/26/06, Chris Withers <chris@simplistix.co.uk> wrote:
Oh please, stop the FUD.
Not FUD, whatever you mean by that here...
Right. FUD is when you intentionally spread unjustified Fear, Uncertainty and Doubt about things to hurt them. You don't. You may HAVE the above things, but if it is justified or not, it's definitely not FUD. :) (I'd say it's justified. Things are happening and happening quickly. It's completely justified to get spooked about that when you rely on stability).
Well, 2.10 is about to be cut, no? That technically makes 2.9 "no longer supported", right? (in the same way that 2.8 is not currently the active maintenance branch...)
No, 2.8 is in active maintenance. 2.8 will go out of active maintenance when 2.10 is cut.
(I think the linux model of 2.odd being dev and 2.even being stable (I may well have those the wrong way round) is designed to prevent excessive branching...
Maybe. It's designed to give you the ability to have resonable release numbers even for unstable branches, instead of calling it "alpha 1, 2, 3, 4" and "beta 1, 2, 3, 4". For me it doesn't make a difference. In fact, I prefer that it is expleicitly called "alpha" or "beta". The stable/unstable numbering scheme is useful if you have a ver long time, like years, betweeen stable releases. We didn't want that. Maybe that was wrong, but I don't think so. It's probably just as much a matter of taste as a matter of what you want out of Zope development.
I don't think there's enough clarity between when something is time based and when something is number based... And, in all honesty, a year is too short a period of time... 2 years is more realistic for most projects I've worked on.
Yes, but two years of what? Don't you think you will have found most bugs after the first year? And if you find more bugs, even after one year these can still be fixed. If they are easy to fix, you can do it. If they are fixed in later versions, somebody can most likely be easily convinced to backport them for a reasonable monetary contribution. If they are weird and obscure bugs that doesn't exist in later versions, or require huge changes in large parts of Zope, well, then you are going to have to switch versions *anyway*. I need to repeat this: Zope 2.7 did not disappear or stop working when Zope 2.9 was released. All that happened was that the people involved in active development of Zope said "right, we are no longer automatically backporting fixes to 2.7". That's is. That's all that happened. My personal sites run on Python 2.1.something and Zope 2.5. They did not explode or stop working When Zope 2.7 came out. 2.5 was released January 25th 2002. Is four years long enough? :) (I'm just nagging you now, don't take it seriously). If Zope would have been a closed source Microsoft software, I would have TOTALLY agreed with you. Because any problem that then pops up is dependant on the support of the company. When MS drops support for a version of software, that's pretty much the death of using that version in a serious project. But Zope is open source. Any problem that is there can be fixed, even if it is not longer "actively maintained".
Sometimes we learn from the past and our views on things change (still think implicit acquisition is a good idea? ;-) ). I'm certainly not trying to put any burden on Andreas, I'm questioning the policies which seem ot have resulted in so many branches that need maintaining...
Well, the only way to cut down on those branches is either to cut down on support of older versions (and you sure don't want that) or cut down the amount of new releases (and I sure don't want that). This means that we have a conflict of maintainability and development, and we need to find the right compromise. I'm not convinced that the current comprmise is not right. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/