[Zope-dev] Re: Zope 2.9 goals

[Jim Fulton]

Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jim Fulton wrote:
> 
>>Tres Seaver wrote:
>>
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>Jim Fulton wrote:
>>>
>>>
>>>>Chris McDonough wrote:
>>>>
>>>>
>>>>
>>>>>On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:
>>>>>
>>>>
>>>>...
>>>>
>>>>
>>>>
>>>>>We have historically always had the opportunity to introduce features
>>>>>that preserve 100% b/c (like filestream iterators) in point releases.
>>>>>This has worked pretty well for the last few years.
>>>>
>>>>
>>>>
>>>>I wasn't aware of this and I don't think it's a good policy.
>>>>
>>>>Feature releases should be backward compatible. Bug-fix
>>>>releases should be for bug fixes.
>>>
>>>
>>>
>>>Agreed, in theory.  In practice, the usual handwave has been to construe
>>>the absence of the feature as a bug (with greater or lesser
>>>justification).
>>>
>>> Perhaps we can be more hard-nosed about a "no new features in third-dot
>>>releases" policy *after* we get a timeboxed release process in place?  I
>>>have some recollection that a hard-nosed application of such a policy in
>>>ZODB land contributed to the creation of the "dead-end" 3.3 release
>>>line, never incorporated in any released Zope2 / Zope3 version.
>>
>>
>>Which is just fine IMO.
> 
> 
> Such an outcome might be "acceptable", but could hardly be called
> "desirable."

I'm not sure what outcome you are refering to.  Surely not the "dead-end"
of 3.3.

> I'll note that a *big* pile of potentially useful ZODB features were
> pretty much inaccessible to the Zope2 community from the date of the
> first 3.3a1 release, nearly two years ago[1], until the release of Zope
> 2.8 last month.  This timespan, eerily enough, coincides almost exactly
> with the  life of the Zope 2.7 release cycle[2].

Of course, ZODB 3.3 was technically incompatible with Zope 2.7
because it required new-style classes.  There's nothing we could
have done to make those features accessable sooner short of a major
architectural change which, frankly, we could not afford.

> I know how and why the loss happened (I helped *make* it happen, I'm
> afraid), but I don't want it to happen again.  Moving to time-based
> releases should help with the problem,  but we aren't there yet,

Right, we are going there. That's what the discussion is about.
We have to start some time. We are going to start in December.
We couldn't start for Zope 2.9 or 3.1 because we were already committed
to changes that were in and needed time to finish.  This won't happen
in the future because we know that something can't be checked into
the trunk unless it is ready for beta and we know that there will be a
definate date for the beta. Anything not in by then won't be in the release.

> and
> won't be for a year (a successful delivery in December could be a fluke).

This makes no sense to me at all.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org