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

[Stefano Lattarini]

Hi Diego, Jack, sorry for the late reply.

On 02/01/2013 06:47 AM, Jack Kelly wrote:
> Diego Elio Pettenò <address@hidden> writes:
>> On 31/01/2013 20:58, Jack Kelly wrote:
>>> IMHO, that seems like a great way to cause trouble for unsuspecting
>>> users. (Anyone remember KDE4.0?) Can you expand on why you think it's a
>>> good plan?
>>
>> Because unlike KDE, automake can put a big fat warning in the generated
>> configure that says "You're using a version unsuitable for production",
>> and then people would understand it much better.
> 
> Or at automake invocation time?
> 
>> KDE 4.0 was a screwup because there was no big fat warning, and users
>> insisted to have it. No user _asks_ for automake.
>>
>>> Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit
>>> the ordering system for most package managers? Bonus points if it works
>>> in asciibetical order, too.
>>
>> Good luck finding one. Gentoo would be fine with X.Y_betaZ — but I
>> honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y
>> for almost everything but autotools..
> 
> Fair points. +1 to calling the betas "X.0".
> 
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?

As for the naming scheme for alpha/beta versions in Automake: I agree it is
suboptimal and a little confusing, its roots being likely based in the messy
1.4 -> 1.6 transition.  So far, it hasn't yet grated on me enough to motivate
me to try to improve it [1]; but if anyone wants to take a shot at that, be
my guest! (that will probably require some mail archive digging and "git blame"
invocations to see who introduced what for which reason).

  [1] In a way that is enough backward compatible, I mean.

Regards,
  Stefano