bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

[Eric Dorland]

* Stefano Lattarini (address@hidden) 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.
> 
>   * 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.

I like it. I think it would mean that Debian could carry less
simultaneous automake packages at the same time, ie it would have a
separate package per major release and just upgrade that to highest
release within that major (eg package automake-2 @ version 2.1.3,
automake-3 @ version 3.0.4).

> 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).
> 
> I also propose the following change to the branching scheme currently
> implemented in the Automake Git repository:
> 
>   * The 'maint' branch will be reserved to cut of the next micro
>     release; so it will just see fixes for regressions, trivial
>     bugs, or documentation issues, and no "active" development
>     whatsoever.
> 
>   * The 'master' branch will be where the development of the next
>     minor release will take place; that is, a sort of "middle-ground"
>     between the roles so far fulfilled by the 'maint' and 'master'
>     branches in the current branching scheme.
> 
>   * The (new) 'next' branch will be reserved for the development
>     of the next major release; it will basically take over the rule
>     that is currently fulfilled by the 'master' branch.
> 
>   * 'maint' will be kept regularly merged into 'master', and
>     'master' into 'next' (and 'next' into the 'ng/master', which
>     is where the Automake-NG codebase currently live).
> 
>   * Feature branches should typically be based off of 'master',
>     and we can decide later whether to eventually merge them into
>     'master' or into 'next'.
> 
>   * None of 'maint', 'master' and 'next' should be rewindable.
> 
> If you agree with my proposal, I think the new schemes could be
> implemented right after the 1.13.2 release; so that the planned
> Automake 1.13.3 will be released as 1.14, and the planned Automake
> 1.14 will be released as Automake 2.0.

I think it would be better to start with the planned 1.14 (aka 2.0)
rather than with 1.13.3. It makes it a cleaner break for people (aka
Debian to some degree) who were relying on the old versioning scheme.
 
> And of course, we'll have to publicize the new versioning scheme
> ASAP, and with quite high visibility.  I propose the following
> avenues:
> 
>   - A news item in the savannah AUtomake page;
>   - A message to autotools-announce;
>   - An entry in the NEWS file of 1.13.2.
>   - ??? (suggestions welcome)
> 
> -*-*-
> 
> Feedback, opinions, objections?
> 
> Regards,
>   Stefano
> 

-- 
Eric Dorland <address@hidden>
ICQ: #61138586, Jabber: address@hidden

signature.asc
Description: Digital signature