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 #8 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13578 <at> debbugs.gnu.org, automake <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, 29 Jan 2013 12:30:04 +1100

Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
> So I propose the following change in the Automake versioning scheme:
>
>   * Major releases should actually have the major version number bumped.
>     That is, the next major Automake version will be 2.0, rather than
>     1.14; and the major version after that will be 3.0; and so on.
>     After all, there is no shortage of integer numbers to use :-)
>     Such major releases can introduce backward-incompatibilities (albeit
>     such incompatibilities should be announced well in advance, and a
>     smooth transition plan prepared for them), and try more risking
>     and daring refactorings.
>
>   * Minor releases have the minor version number bumped (1.13 -> 1.14
>     -> 1.15 ...), can introduce new "safe" features, do non-trivial
>     but mostly safe code clean-ups, and even add new runtime warnings
>     (rigorously non-fatal); but they shouldn't include any backward
>     incompatible change, nor contain any potentially destabilizing
>     refactoring or sweeping change, nor introduce new features whose
>     implementation might be liable to cause bugs or regressions in
>     existing code.
>
>   * Micro releases (1.14.1, 1.14.2, ...) should be just bug-fixing
>     releases; no new features should be added, and ideally, only
>     trivial bugs, recent regressions, or documentation issues should
>     be addressed here.

This sounds quite resonable to me, but is there anyone who is relying on
automake versions taking the form 1.x.y? It might be worth reaching out
to the distro packagers, just in case.

-- Jack

Previous Next

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