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

[Carter Bullard]

Hey Andrew,
   You've definitely made a good case that its broken,
so lets fix it.  I don't have a scheme in mind, so if
you've got a strategy that works, lets adopt it!!!!

   I was hoping that 2.0.6 was done, frozen, finished,
etc.... and that we would be moving on to whatever new
number was next, but I haven't 'announced' it officially, so
I think we have an opportunity to go ahead and specify a
system and use 2.0.6[whatever] as the guinea pig.  If
it's an even odd thing that would be fine, if its another
extension, that's cool.  Preferably one that has some
legs in the real world.

   My desire is that we can build packages like tar'z,
rpm's etc easily.   I have no idea (sorry about that)
what Debian likes, but hopefully whatever we decide on
can accommodate many of the popular packaging strategies.

Hope all is very well!!!!

Carter





-----Original Message-----
From: owner-argus-info at lists.andrew.cmu.edu
[mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Andrew Pollock
Sent: Friday, June 25, 2004 2:10 AM
To: argus-info at lists.andrew.cmu.edu
Subject: [ARGUS] Argus release strategy (and version numbering scheme)
(longish)

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