Chris Withers wrote:
> Philipp von Weitershausen wrote:
>> Chris Withers wrote:
>>> Florent Guillaume wrote:
>>>> Chris Withers wrote:
>>>>> Both core zope and Plone spew forth in their default state.
>>>> Zope 2.10 does? It shouldn't. Please point out the deprecation
>>>> warnings it sends.
>>> I, like many people I suspect, am still struggling to get projects onto
>>> 2.8/2.9. The thought that they're both going to be "obsolete" already
>>> fills me with dread :-(
>> Oh please, stop the FUD.
> Not FUD, whatever you mean by that here...
I'm referring to your handwaving based on false information. "Dread" as
you call it above is typically defined as the "anticipation of
apprehension of fear" (Oxford American Dictionary). Spreading fear based
upon false information is pretty close to FUD, I'd say.
>> Zope 2.9 is well within its normal release cycle and not going out of
>> style for a long time.
> Well, 2.10 is about to be cut, no? That technically makes 2.9 "no longer
> supported", right?
Nope. Zope 2.9 is in bugfix mode, at least for another 6 months and
beyond that as long as people want to support it.
> (in the same way that 2.8 is not currently the active
> maintenance branch...)
Still wrong. Zope 2.8 is still maintained. Andreas hasn't said anything
yet about not making any more Zope 2.8 releases.
> If what we're really saying is that we've agreed to keep the previous
> two release branches maintained, then I assert we're branching too often
> (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...
As Martijn pointed out already, this model makes it difficult to get
features released at a definite point in time. Zope 2.7 and 2.8 were
releases bloated with features that seemed to have taken forever. Zope
2.7 took more than two years. Zope 2.8 took more than one year and could
be right up with Zope 2.7 if it hadn't been for Five.
>> Andreas had the idea of phasing out Zope 2
>> releases one year after their first release, which would mean that Zope
>> 2.8 would be phased out soon, but not yet.
> I don't think there's enough clarity between when something is time
> based and when something is number based...
I think there's lots of clarity. We make a major release every six
months. That's the 'y' in x.y.z. Then the release managers may decide to
make minor releases based on the number and necessities of bugfixes
during the maintenance period. This is the 'z' in x.y.z.
> 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.
Fine. Nobody said that we can't change this policy. BUT, just because
you have Zope 2.7 in production doesn't mean we still need to actively
maintain Zope 2.7. Of course, everyone's free to still do so if s/he
needs bugfixes in there, but so far that hasn't happened. You're really
the only one "complaining" so far, and actually haven't given any
examples yet of where you see a problem with Zope 2.7 not being
maintained anymore. Or Zope 2.8, for that matter (even though it still is).
>> Plus, if you care to make more Zope 2.8 releases, by all means, do it.
>> But don't burden Andreas with even more work when YOU once agreed to his
>> very policy (see
> 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...
Sure, we all change our views. I think the number of branches isn't
a problem, though. They seem to retire themselves pretty quickly (about
a year after the initial stable release).
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -