[Zope3-dev] Zope 3 release planning

[Stephan Richter]

On Thursday 17 February 2005 06:21, Martijn Faassen wrote:
> The only reproducable way I know of to do a release (sort-of) on time is
> to *ignore* certain issues for the time being and defer them into the
> future. You can always do a bugfix release, or, since your next release
> is coming up in a forseeable future, just wait until the next release.

Maybe it would be worth to change our release strategy to one that is like the 
Kernel one. Let's declare odd major version numbers as unstable and make even 
release numbers stable releases. This way, features will be released sooner.

On the other hand, this might not be necessary, since the trunk is always 
stable. From what I know, several of the large projects use the trunk. 
Honestly, what does a release do that the trunk does not offer, if we ignore 
bugs and XXX statements?

The high-quality mandate of the Zope 3 development process gives our trunk 
more stability than many other project's releases. So what are the advantages 
of a release?

- Developers concentrate on bug fixing instead of features.

- The word of a release usually reaches beyond the Zope community, which means 
exposure.

- There is a sense of a milestone that has a well-defined set of features and 
API.

I think that all three of those are very important, but I am not sure they are 
a reason to release prematurely. BTW, for Zope 3 we use the motto "Speed 
kills!"

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training