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:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to