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

[Steve McInerney]

I don't think you really need the votes, and operating on the principle 
that some feedback is better than none :-)  this concept looks very 
workable.

Andrew seems happy with it, and if Debian is happy, then I would suspect 
everyone else would tend to use similar logic and be happy too.

Having the "z" "z+1" concept makes it very clear that one is unstable, 
t'other is stable.
Definate positive.


Looks fine to me!


- Steve


Carter Bullard wrote:
<snip>
> 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)

<snip>