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 comment there.)

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

Reply via email to