Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

[Stefano Lattarini]

On 02/12/2013 09:25 AM, Miles Bader wrote:
> 2013/2/12 Stefano Lattarini <address@hidden>:
>>>> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
>>>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
>>>> you are proposing?
>>>
>>> There's always 1.14.0.1, ...
>>>
>> Yuck; the new versioning scheme is done exactly to avoid that kind
>> of overly long version numbers
> 
> Well, I agree in general that too many components is yucky, but keep
> in mind that these _aren't releases_, so assigning them "awkward"
> version numbers doesn't really seem all that annoying.  These really
> aren't part of the historical record.  The existing naming scheme for
> betas does the same thing (uses "weird" version numbers), but is
> problematic because it's not mechanically consistent with "ordinary"
> version numbers (and so screws up cases such as packaging software).
>
Mostly fair points; but the biggest issue with this proposal (not
sure why I didn't think of it before, sorry) is that it is not at
all clear that a version like "1.13.0.1" is supposed to be a beta
release.  People will easily mistake it for a stable release.  OK,
we can add warnings and info and whatnot in the manual and homepage
of automake about our unusual versioning scheme, but how many people
will read them?  And in the end, even those who do will likely be
just annoyed by the fact that we are trying to be clever and invent
a new versioining scheme incompatible with every other existing one.

No, if we want to change the versioning scheme for beta and rc
versions, we want the new scheme to be already used and well known.

> I do agree that removing the leading "1." might be a good idea if it's
> meaningless in practice.  Linux's similar action was good.
> 
> -miles
> 
> --
> Cat is power.  Cat is peace.

Thanks,
  Stefano