[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases

From: Peter Johansson
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 22:18:52 +1000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv: Gecko/20120306 Thunderbird/3.1.20

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:

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:
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


Peter Johansson

reply via email to

[Prev in Thread] Current Thread [Next in Thread]