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

View this message in rfc822 format

From: Peter Johansson <trojkan <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13578 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Date: Tue, 29 Jan 2013 22:18:52 +1000

Hi Stefano,


On 1/29/13 5:48 AM, Stefano Lattarini wrote:
> Severity: wishlist
>
> Recently, the need of a quick bug-fixing release 1.13.2 has shown some
> issues with the current branching and versioning scheme of Automake.
>
> Let's first see some background, to better understand the situation.
>
> Given the typically long time between a major release 1.N and the next
> one 1.(N+1) (say, 1.11 and 1.12), I had begun, in the last year or so,
> to introduce some (mostly) safe and backward-compatible but non-trivial
> changes and enhancements between a minor release 1.N.M and the next one
> 1.N.(M+1) (say, 1.12.1 and 1.12.2).
>
> As an example of such changes, in the NEWS entry for 1.12.2 we have:
>
>    - Recursive cleaning rules descends into the $(SUBDIRS) in the natural
>      order (as done by the other recursive rules), rather than in the
>      inverse order.  They used to do that in order to work a round a
>      limitation in an older implementation of the automatic dependency
>      tracking support, but that limitation had been lifted years ago
>      already, when the automatic dependency tracking based on side-effects
>      of compilation had been introduced.
>
> And in the NEWS entry for 1.11.3 we have:
>
>    - For programs and libraries, automake now detects EXTRA_foo_DEPENDENCIES
>      and adds them to the normal list of dependencies, but without
>      overwriting the foo_DEPENDENCIES variable, which is normally computed
>      by automake.
>
>    - "make dist" can now create lzip-compressed tarballs.
>
> This approach has however shown several drawbacks since its introduction:
>
>    * Such changes might be not trivial, and their correct implementation
>      and testing can leave the maint branch in a non-safely-releasable
>      state, thus complicating the cut of a urgent bug-fixing release.
>
>    * Given the current maint/master branching scheme, the sudden need
>      of such a release forces us to mess with the planned version numbers
>      and the branching setup, since we might not be able to cut such
>      a release from maint (as that might already contain some changes we
>      consider inappropriate for a mere bug-fixing release).
>
>    * Some bug-fixes (especially for for old bugs) or code clean-ups and
>      refactorings (especially for old or complex code) might cause
>      backward-incompatible changes in the semantics of some corner-case
>      behaviours; that can unpleasantly surprise users who are thinking
>      they are getting only basic bug-fixes, and get instead bitten by an
>      unexpected behavioural change.  Such users might rightfully complain
>      that, while they approve the change and are well ready to adapt
>      their packages to it, they don't expect to be forced to do so when
>      upgrading to a mere minor release.  See for example:
>      http://lists.gnu.org/archive/html/bug-automake/2012-07/msg00107.html
>
> 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.
Will it still be linear, or do you expect any 1.x release after 2.0?

>    * 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.
>
IMVHO, this is how it always has been, except the last year or so. See 
for example release of Automake 1.10.2, which only fixed a couple of 
bugs. Change of behaviour (like recursive cleaning mentioned above) or 
optimizing the code never belong in a micro release. I'm glad you clary 
this.


> Another plus of this new versioning scheme is that it will allow
> different minor releases, even with the same major version, to
> co-exist on the same system (that's because the $(APIVERSION)
> variable will get bumped with each minor version now).

Why is that a plus? What is the use case when I want to keep on using 
Automake 2.1 after I have installed Automake 2.2? Assuming 2.2 is 100% 
backward compatible I cannot see the use case. What am I missing?

In general I like the clarification, but I wonder what the expected 
frequency of major/minor releases are. If you expect more major releases 
than minor releases, the future series of versions would look something 
like:
2.0
2.0.1
2.0.2
2.1
3.0
3.0.1
4.0
...
In other words if the minor releases are rare, the middle digit has no 
function and it could be removed with no loss:
2.0     -> 2.0
2.0.1  -> 2.1
2.0.2  -> 2.2
2.1     -> 3.0
3.0     -> 4.0
3.0.1  -> 4.1
4.0     -> 5.0

or just keep the scheme as is
1.14
1.14.1
1.14.2
1.15
1.16
1.16.1
1.17


Cheers,
Peter

-- 
Peter Johansson

Previous Next

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