[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Wed, 30 Jan 2013 16:07:09 -0500
* 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:
> 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
> * 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
> - 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?
Eric Dorland <address@hidden>
ICQ: #61138586, Jabber: address@hidden
Description: Digital signature
- [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Stefano Lattarini, 2013/01/28
- Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Jack Kelly, 2013/01/28
- Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Thien-Thi Nguyen, 2013/01/29
- Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Peter Johansson, 2013/01/29
- Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Daniel Herring, 2013/01/29
- Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository,
Eric Dorland <=
- Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Diego Elio Pettenò, 2013/01/31