[ARGUS] Argus release strategy (and version numbering scheme) (longish)

[Andrew Pollock]

Hi Carter,

I've been procrastinating on packaging up the final release of Argus 2.0.6
for Debian, largely due to the version numbering used giving me some grief.

I've also noticed on the Argus webpage that there are bugs in the final
release, that you've acknowledged, but only fixed in the development
release.

So my question to you is, now that Argus 2.0.6 has been released, is it your
intention not to touch that again, and only fix bugs in the betas for 2.0.7
(or whatever you're going to call it), or do you intend to make point
releases of 2.0.6 solely to address bugs?

Secondly, I'd like to ask you to come up with a more sane version numbering
scheme, as the version numbering scheme used for the 2.0.6 betas and release
candidates presents some problems, specifically using this example:

argus-2.0.6.alpha.1
argus-2.0.6.beta.1
argus-2.0.6.rc1
argus-2.0.6

Doing version numbering comparisions, the alphas are lower than the betas,
and the betas are lower than the release candidates, however the final
release is not considered a higher number than the release candidates (or
the alphas or betas), which makes upgrading rather difficult for people
using packaged versions of the prerelease stuff. 

Unfortunately, as I inherited the Debian packaging, there wasn't a lot I
could do, as the betas were already packaged and in Debian. I've now got to
choose between fudging the Debian version of 2.0.6 as "2.0.6.release" or use
an epoch (which a lot of Debian developers seem to have a strong aversion
to) to make 2.0.6 appear to be a higher version number than 2.0.6.rc4.

So, I'd like to try and avoid these problems going forward with future
versions. I wonder if you could incorporate the status of the release into
the version as a number, similar to the way the Linux kernel does it, or
otherwise rejig the numbering. Maybe number 2.0.7 as 2.1, when it comes to
actually release it, and then continue subsequent development as 2.2? Or
designate anything with a third component of it's version number prerelease?
I don't know, it's your call. I just wanted to float the idea...

I guess also if 2.0.6 (as a released version) isn't going to change, end of
story, then I can probably fudge it as 2.0.6.release or something, rather
than use this epoch thing, but if you're likely to do a proper 2.0.6.1 that
fixes for example the -F bug, then it might make sense to epoch it instead.

For what it's worth, I don't think Debian is the only distribution that is
likely to strike version comparision issues, I would think RPM will also
have a bit of a cry. Workarounds might include removing the old package and
installing the new, but this is contrary to the smooth upgrading that Debian
provides.

regards

Andrew