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

[Andrew Pollock]

On Wed, Jun 30, 2004 at 09:00:02AM -0400, Carter Bullard wrote:
> 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)

Hi,

This sounds pretty reasonable to me. If you want to re-release 2.0.6 as
2.0.8, that's fine. It means I can avoid this epoch thing in the version
number, which is a permanent thing.

Quick test:

$ dpkg --compare-versions 2.0.6.alpha.1 lt 2.0.6.beta.1 && echo smaller || echo bigger smaller
smaller
$ dpkg --compare-versions 2.0.6.beta.1 lt 2.0.6.rc.1 && echo smaller || echo
bigger
smaller
$ dpkg --compare-versions 2.0.6.rc.1 lt 2.0.7 && echo smaller || echo bigger
smaller
$ dpkg --compare-versions 2.0.7 lt 2.0.7.fixes.1 && echo smaller || echo
bigger
smaller

so this stands up from a "newer versions compare higher" standpoint.

Thanks for considering this.

regards

Andrew