[Zope-dev] Re: Flood of deprecation warnings...

[Lennart Regebro]

On 6/26/06, Chris Withers <chris at 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/