Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
On 01/28/2013 08:48 PM, 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. > > * 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 > 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. > > 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 > OK, so far I've seen only positive feedback about this proposal. There are still some unresolved issues about how to handle beta releases; but the related proposals can be seen as a refinement of my scheme, not as something incompatible or in competition with it. So I see no reason to hold back the implementation of my proposal on their account: we can implement those refinements later, once some consensus is reached and the details are worked out. So, if I see no further objections, I'm going ahead with my proposal in a few days. Thanks, Stefano
