[Top][All Lists]

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

[debbugs-tracker] bug#13578: closed (A new versioning scheme for automak

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#13578: closed (A new versioning scheme for automake releases, and a new branching scheme for the Git repository)
Date: Sat, 23 Feb 2013 17:49:03 +0000

Your message dated Sat, 23 Feb 2013 18:46:38 +0100
with message-id <address@hidden>
and subject line [IMPORTANT] *Implemented* a new versioning scheme for automake 
releases, and a new branching scheme for the Git repository
has caused the debbugs.gnu.org bug report #13578,
regarding A new versioning scheme for automake releases, and a new branching 
scheme for the Git repository
to be marked as done.

(If you believe you have received this mail in error, please contact

13578: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Date: Mon, 28 Jan 2013 20:48:59 +0100
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.

  * 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.

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

  * 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.

And of course, we'll have to publicize the new versioning scheme
ASAP, and with quite high visibility.  I propose the following

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


--- End Message ---
--- Begin Message --- Subject: [IMPORTANT] *Implemented* a new versioning scheme for automake releases, and a new branching scheme for the Git repository Date: Sat, 23 Feb 2013 18:46:38 +0100
On 02/21/2013 04:06 PM, Stefano Lattarini wrote:
> On 02/21/2013 03:32 PM, Stefano Lattarini wrote:
>>> Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as
>>> well as few miscellaneous comments in tests and scripts).  Then we can
>>> finally proceed with the re-shuffling of the Git repository -- which I
>>> guess will also have to be announced in autotools-announce at least, as
>>> well as reported as a news on Savannah.
>>> So here is my attempt; OK to push to branch-1.13.2?  I will proceed in a
>>> couple of days if there is no objection.
>> Pushed now.
> In a couple of days, I will proceed with this "branch moving":
>    * branch-1.13.2 -> maint
>    * maint -> master
>    * master -> next
Done.  I'm thus closing this bug report.

Note that there are still some pending, tentative proposals about how to
improve the names and release policy for beta versions; but since those
proposals are more a follow-up to this discussion than an integral part
of it, they are IMO more suited to be further discussed in new, dedicated
threads.  So, if anyone is still interested in pursuing those ideas, please
open a new bug report (preferably complete with references to the relevant
messages in this thread, and with a summary of the main ideas, motivations,
and consensus -- or lack thereof -- reached so far).

Thanks to all that have participated to this discussion, and offered
their feedback, ideas and experiences.

Best regards,

--- End Message ---

reply via email to

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