[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