[ARGUS] Argus release strategy (and version numbering scheme) (longish)
slif at bellsouth.net
slif at bellsouth.net
Wed Jun 30 20:13:52 EDT 2004
Andrew Pollock wrote:
>On Wed, Jun 30, 2004 at 09:00:02AM -0400, Carter Bullard wrote:
[SNIP]
>>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
>
Soliciting my opinion can be dangerous.
I might just provide one!
There is a 2.0.6.fixes.1 tarball, which IMO should not change numbers.
Why ? Because it has already been published; Changing its version now
would only create confusion.
Recommend that a new source release be cut soon, and that follows
the version numbering/naming guidelines which are agreed to.
If 2.0.6.fixes.1 is considered stable, it would seem
that 2.0.8 is a good version label for its successor.
Best Regards,
-Mike Slifcak
More information about the argus
mailing list