GNU bug report logs -
#13578
A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Previous Next
Reported by: mthl <at> gnu.org
Date: Mon, 28 Jan 2013 19:50:02 UTC
Severity: wishlist
Tags: fixed
Done: Mathieu Lirzin <mthl <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #14 received at 13578 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 7 years and 248 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.