Benji York wrote:
Personally I think we should just release the trunk every six months
(with a list of known bugs) and that be it. (I'm speaking of Zope 3
here, I don't know enough about the dynamics of the Zope 2 ecosystem to
What good could that possibly do?
For the people who are not spending their days reading checkin messages,
something that is called a final release is a promise that the features
they get have been tested and are considered stable, that they can rely
on a certain degree of backwards compatibility, and that they're going
to get burned.
Releases are externally-facing things. They benefit people other than
the core contributors the most (the core contributors mostly get the
gratification of having released something, and then probably go on
playing with trunk). The quality those people receive must be the most
important factor by which a release is judged.
.0 releases of Zope (2) have had a somewhat negative image before (to
the point where people were afraid to let Plone depend on a Zope release
that didn't have a .1 or .2 release out already), which I think is
getting better. Undoing that would be to the detriment of how people
perceive the quality of our software.
By the same token, we could just never have releases and expect everyone
to live off svn trunk. The idea of a release *cycle* is surely that it's
cyclical: at the beginning, we worry about features and innovation, at
the end we worry about stability and polish. If the timelines are worked
out correctly, then time-based releases help us manage scope and keep
moving at a pace that doesn't mean we have enormous mountains of
features that take an infinite amount of time to stabilise and get ready.
That's a good thing, but ignoring the end-result quality argument by
being slaves to the Great Roadmap that was set out six months ago isn't.
It's very waterfall. :)
Martin (pardon any hyperbole)
Zope3-dev mailing list