GNU bug report logs - #13578
A new versioning scheme for automake releases, and a new branching scheme for the Git repository

Previous Next

Full log

Message #91 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Vincent Torri <vincent.torri <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org,
	Jack Kelly <jack <at> jackkelly.name>, Miles Bader <miles <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 09:42:31 +0100

On Tue, Feb 12, 2013 at 9:38 AM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> On 02/12/2013 09:25 AM, Miles Bader wrote:
>> 2013/2/12 Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>>>>> 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.

in our project, we append _beta and _rc (or _rc1, _rc2 etc...) for
beta and release candidate. It's sufficiently explicit. For example,
1.14.0_beta

Vincent Torri

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.