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
