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

[Stefano Lattarini]

Hi Miles.

On 02/12/2013 12:50 AM, Miles Bader wrote:
> Stefano Lattarini <address@hidden> writes:
>> 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 -- otherwise, we could just have
1.13.1.1 as bug-fixing release, 1.13.2 as new minor release, and
1.14 as new major release.  But if that leading "1" is going to
remain unchanged anyway, what is the point of keeping it?  It's
just "visual noise" IMO.

(In addition, the current version-checking code in Automake only
grasps version numbers with at most three numbers).

> Or the widely used in FOSS 1.13.99...
> [sometimes they start at "90", to leave room for updates,
>
This might work.  But see below.

> but I suppose you could always just use .99.1, .99.2, ...]
>
(No, because, as said above, I don't want to have version numbers
with four or more components)

Anyway, before changing the current naming scheme for beta versions,
we'd need some numbers about which the most widespread naming
schemes are, and weight their advantages and disadvantages w.r.t.
our "workflow"; we don't want to trade the current naming scheme
for another that is only marginally more popular, or for a one that
will give use a new and bigger set of problems down the road.

Thanks,
  Stefano