[Dovecot] Version Numbering and releases

Peter Lindgren peter at norrskenkonsult.com
Sat Mar 31 15:56:00 EEST 2007


Hi all,
Merging the two large recent threads, my recommendation is as follows:

* The Release Candidates for 1.0 should be bug fixes only.
* Each new Feature, or a Feature Set, goes in a separate branch.
* That branch is tested by those who need/want that feature.
* When testing is completed, the branch is merged into the main trunk.

This way, we will have fairly well tested features/feature sets in the 
main trunk which people can fairly safe download and test and deploy, if 
their own tests succeeds.

When the feature code is merged into the main trunk, the minor version 
is incremented by one (1.0.x --> 1.1.0).

Bug fixes increment the revision (1.1.0 --> 1.1.1).

Easy to follow, easy to package for package maintainers. Also, it's easy 
to write Readme's and other documentation on what's changed.
(And for those who think that odd versions are for development 
(unstable), well, they will just wait until sufficient features have 
been added before they think it is stable... )

Timo's new features he sees for future versions, plan them for a 2.0 or 
a 1.1 or whatever version number, just don't call it 1.0.2rc1 :-)

Another suggestion, is to create a Bugzilla (or similar) site for 
dovecot. That gives us all a chance to track changes and bug fixes.

/Peter, building rc29 as I write this


More information about the dovecot mailing list