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

[Carter Bullard]

Well, we're on a loose bi-annual release strategy for Argus.
I like that and will try to stick with it, so we're on a May
November release cycle right now.

We still don't have any suggestions on version numbering,
which I believe is Andrew's primary problem.  Our current
strategy is:

   argus-x.y.z.alpha.x   development versions
   argus-x.y.z.beta.z    test versions
   argus-x.y.z.rc.x      release candidates
   argus-x.y.z           stable release

Andrews primary problem is that he builds the test and
release versions and includes them in Debian, and
then when the release comes out, the release number looks
like its "less than".  So, what to do?

I'm in favor of a discipline like this:

   argus-major.minor.version[.stage.#]

   Major release incremented with significant data format changes
      that introduce data incompatibility with earlier versions.

   Minor release incremented with significant feature changes that
      distinguish this release from the prior release (the major and
      minor numbers are advertised in the starting management record
      so clients that read the data can make a parsing decision based
      on the two numbers).

   Version number changes with every release.

   Stage is optional with values:
        stable release: '', fixes
      unstable release: alpha, beta, rc

   Stable release    - vers is always even.
   Unstable release  - vers is always odd.

A whole release cycle would then look like this:

   argus-x.y.z.alpha.w
   argus-x.y.z.beta.n
   argus-x.y.z.rc.r
   argus-x.y.z+1
   argus-x.y.z+1.fixes.y

where z is always odd.

With this suggestion we can renumber argus-2.0.6 to argus-2.0.8,
or leave it the same, depending on whether Andrew needs a version
renumber to solve his problem.

Need opinions here, or its not going to change ;o)

Carter


-----Original Message-----
From: eric [mailto:eric at catastrophe.net]
Sent: Wednesday, June 30, 2004 4:10 AM
To: Andrew Pollock
Cc: Carter Bullard; argus-info at lists.andrew.cmu.edu
Subject: Re: [ARGUS] Argus release strategy (and version numbering scheme)
(longish)

On Sat, 2004-06-26 at 06:31:37 +1000, Andrew Pollock proclaimed...

> Daily builds works fine for Debian. Debian releases a stable version once
in
> a blue moon, so as long as I can get a respectable version of argus and
> argus-clients into that stable release, I'm happy...

For this reason, perhaps taking into account the lowest common
denominator would be best. For instance, OpenBSD is released on a
biannual schedule in May and November. The ports of OpenBSD, like
many others, are maintained at a certain level and only the most
critical bug fixes (usually those that cause a security
vulnerability in the underlying operating system) are pushed into
the ports tree as an announced fix. Anything else (like a minor, or
sometimes even a major, feature waits until the next version of the
OS is released and it's respective ports tree.

That said, perhaps it's best to maintain both a HEAD version and a
stable version of argus. With this, Andrew would be able to track
HEAD (or possibly a -current, slightly less bleeding-edge than HEAD)
and make builds nightly if anything diff's. We can call it a duck, a
cow and a horse...no matter to me! But having a version scheme gets
my vote! Even having a CVS tree would be good too, just to watch the
historical changes. I'll even offer to host it :-)

Cheers,

- Eric