I'd like to suggest a change in the versioning paradigm, to start with
the upcoming 6.0.0.
I have been watching fetchmail more closely for quite a while now, and
in the 5.9.X branch, we had a lot of important bug fixes for greater
values of X, like security fixes, fixes to the SSL hangs, many fixes
contributed by Sunil Shetye, intermixed with new features, and other
hacks that prevent distros from just updating to the latest fetchmail
versions; think of all the unfortunate NLS hassle around 5.9.12.
The sad thing is that many distributions have NOT adopted to the latest
fetchmail version, and as a result, many people still run fetchmail
5.9.0 "gold" which should by all due respect be renamed 5.9.0 "danger"
as it turned, and most will get their fetchmail hung hogging down the
CPU on errors that happen below SSL.
I aim to branch fetchmail in two:
* a "gold" branch that contains only bug fixes, but no new features or
policy changes (unless these fix bugs, of course). I suggest versions
6.0.0, 6.0.1, 6.0.2, with the last component designating the "patch
level" or "bug fix release level".
* a "devel" branch that receives new features, policy changes,
whatever, and that /of course/ gets the bugfixes of the (6.0.X) gold
branch merged. On the versions for this later.
I believe this comes without much additional effort except maybe using
"cvs -b" from time to time.
On the versioning, I have two version number approaches to offer:
* Linux-Kernel: This would mean gold branches start off at 6.0.0,
6.2.0, 6.4.0 and so on. Development branches would be called 6.1.0,
6.3.0.
* Postfix: This means gold branches start off at 6.0.0, 6.1.0, 6.2.0
and so on. The development releases are named after the gold release
they are based on (or what bug fixes from the gold branch have been
merged) and get a date and possibly a tag, so 6.0.0-20020915 would
be the first devel version based on 6.0.0, 6.0.0-20020919 the second
devel release, 6.0.1-20020923 would then be the third devel release,
which had the bug fixes that went into 6.0.1 merged.
A variant would be to use 6.0.0-devel1, 6.0.0-devel2, 6.0.1-devel3
and so on.
Some reasoning: Considering that version numbers can be read as
"MAJOR.MINOR.PATCHLEVEL", people can than expect the MINOR number to
change as the feature set changes, and PATCHLEVELS to just pertain to
bugs. Distributors will love it. It's also easier for users, telling
them "retry with the latest 6.0.X".
Personally, I'd prefer the Postfix version number approach because you
can then easily see which bug fixes are in the devel version as well.
--
Matthias Andree