GNU bug report logs - #13578
A new versioning scheme for automake releases, and a new branching scheme for the Git repository

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13578 in the body.
You can then email your comments to 13578 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Automake List <automake <at> gnu.org>, bug-automake <at> gnu.org
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:
    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

Message #8 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13578 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 29 Jan 2013 12:30:04 +1100

Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
> 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.

This sounds quite resonable to me, but is there anyone who is relying on
automake versions taking the form 1.x.y? It might be worth reaching out
to the distro packagers, just in case.

-- Jack

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thien-Thi Nguyen <ttn <at> gnuvola.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: [IMPORTANT] A new versioning scheme for automake releases,
	and a new branching scheme for the Git repository
Date: Tue, 29 Jan 2013 08:09:28 +0100

[Message part 1 (text/plain, inline)]

() Stefano Lattarini <stefano.lattarini <at> gmail.com>
() Mon, 28 Jan 2013 20:48:59 +0100

   So I propose the following change in the Automake versioning scheme:
   [...]

Sounds good.  Going further, you could maybe define notation (described
in HACKING) for categories of changes (backward-{in}compatible, etc) and
methodically use them in the ChangeLog entries.  This would be both
informative to the user, and helpful to prevent mistakes (by casual
contributors :-D).

   I also propose the following change to the branching scheme currently
   implemented in the Automake Git repository:
   [...]

These details should also be explained in HACKING.

   to publicize the new versioning scheme

     - ??? (suggestions welcome)

Maybe cut a release that changes only the version number?  Personally i
would find that to be not particularly useful, but others might welcome
the explicitness.

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[Message part 2 (application/pgp-signature, inline)]

Message #14 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13578 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 29 Jan 2013 22:18:52 +1000

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

Message #17 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Dave Goodell <goodell <at> mcs.anl.gov>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: automake <at> gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>,
	13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 29 Jan 2013 08:22:42 -0600

On Jan 29, 2013, at 6:18 AM CST, Peter Johansson wrote:

> On 1/29/13 5:48 AM, Stefano Lattarini wrote:
> 
>> 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?

As a developer, it can be surprisingly difficult to write autotools code that is portable to several different versions of the autotools.  Sometimes it's convenient to only choose to support some subset of the autotools version space.  Development bandwidth, lack of autotools expertise, and limited access to testing platforms are all reasonable reasons that lead to this sort of decision.

This in turn causes problems for packagers, since different packages choose different subsets of the versions space.  So as a packager, you end up either:

1) attempting to patch all of the packages which are incompatible with your versions of the autotools, which is risky and time-consuming; or

2) juggling several different autotools version tuples.  Anything that makes this difficult quickly can turn into a real PITA.  Anything that makes it easier is always welcome.

Putting the developer hat back on, facilitating multiple versions also makes it easier to test with each of those versions.

-Dave

Message #20 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 13578 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 29 Jan 2013 19:32:19 +0100

On 01/29/2013 01:18 PM, Peter Johansson wrote:
> Hi Stefano,
>
Hi Peter and everybody, and thanks for the feedback.

> [SNIP]
>
> Stefano Lattarini wrote:
>
>> 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?
>
Ideally, it should still be linear.  We could easily create an 'old-release'
branch from the last 1.x release, and backport  bug fixes implemented in
the 2.x series there; but I'd rather not do so, unless there is a strong
demand from the user base.

>>    * 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.
>
Yes, my bad there, sorry.  This is an attempt to remedy to it, and
improve the release scheme a little in the process.

> 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
> clarify this.
>
I should have probably done it earlier.  Well, better late then never.

>> 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?
>
The fact that a change like the "recursive cleaning" mentioned above
might have broken, in 2.2, some tricky usages in your makefiles, usages
that used to work in 2.1; and you might not want (or be able to) adjust
them right away.

> Assuming 2.2 is 100% backward compatible
>
That cannot be guaranteed, as some bug fixes might break some corner-case
usages (especially when bugs were being used as features, through no fault
or abuse of the user; see for example <http://debbugs.gnu.org/11030>); this
is why I think this kind of bug-fixes should go in a new minor release,
rather than in a micro release.

Moreover, a new minor release could add new (non-fatal) warnings that were
not present in the previous one, and this too amount to a small backward
incompatibility (or not so small, if you are making the mistake of having
'-Werror' in AUTOMAKE_OPTIONS).

> I cannot see the use case. What am I missing?
>
Is the answer above enough?

Anyway, notice that the allowed co-existence of minor releases would only
be a side effect of the proposed change, and not a motivating factor.  So
even if it turns out to be mostly useless, that is no problem.

> In general I like the clarification, but I wonder what the expected
> frequency of major/minor releases are.
>
Ideally, we should aim for a major release once a year (or longer, even),
a minor one every two or three months, and a micro one whenever needed.

> If you expect more major releases than minor releases,
>
I don't (albeit this concern of yours is something to be kept in mind).

> 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
>
The whole point of this proposal is that minor releases (not merely
bug-fixing ones) have been proving to be quite common recently :-)

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

Thanks,
  Stefano

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Thien-Thi Nguyen <ttn <at> gnuvola.org>
Cc: bug-automake <at> gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: [IMPORTANT] A new versioning scheme for automake releases, and
	a new branching scheme for the Git repository
Date: Tue, 29 Jan 2013 19:44:48 +0100

On 01/29/2013 08:09 AM, Thien-Thi Nguyen wrote:
> () Stefano Lattarini <stefano.lattarini <at> gmail.com>
> () Mon, 28 Jan 2013 20:48:59 +0100
> 
>    So I propose the following change in the Automake versioning scheme:
>    [...]
> 
> Sounds good.  Going further, you could maybe define notation (described
> in HACKING) for categories of changes (backward-{in}compatible, etc)
>
Fully agreed; and abridged version of this proposal is to land in HACKING
soon(ish).

> and methodically use them in the ChangeLog entries.
>
This would be overkill IMVHO.

> This would be both informative to the user, and helpful to prevent
> mistakes (by casual contributors :-D).
> 
>    I also propose the following change to the branching scheme currently
>    implemented in the Automake Git repository:
>    [...]
> 
> These details should also be explained in HACKING.
>
Again, +1

>    to publicize the new versioning scheme
> 
>      - ??? (suggestions welcome)
> 
> Maybe cut a release that changes only the version number?
>
> Personally I would find that to be not particularly useful, but others might
> welcome the explicitness.
>
Sounds overkill, and some people might even be annoyed by this ("you made
me upgrade my installation only to bump the version number ?!?").  I'd
rather avoid that.

Let's hope a clear NEWS entry in 1.13.2 will be enough to catch the eyes
of enough people.

Thanks,
  Stefano

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Herring <dherring <at> tentpost.com>
To: Automake List <automake <at> gnu.org>, bug-automake <at> gnu.org
Subject: Re: [IMPORTANT] A new versioning scheme for automake releases, and
	a	new branching scheme for the Git repository
Date: Tue, 29 Jan 2013 22:30:47 -0500 (EST)

On Mon, 28 Jan 2013, Stefano Lattarini wrote:

> Feedback, opinions, objections?

There was a lot to read, and I confess to not giving it full justice.

Others have already extolled the virtues of backwards compatibility.


Regarding some "why" questions, here's the manual entry on how versioning 
is used today.

http://www.gnu.org/software/automake/manual/html_node/API-Versioning.html


As far as I can tell, the current proposal boils down to "bump the major 
version more often".  That can work, but I'm not quite sold on it.  I like 
when a major bump means "wake up and reread the docs before upgrading" and 
minor bumps mean "upgrade casually".  (and aggregate changes to minimize 
major bumps and make them more worthwhile)

Here are a couple "standards" for versioning.

http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
http://semver.org/

The general principle being A.B.C decodes to something easy like
A = new API, breaking changes requiring human intervention
B = same API, maybe with added options, mostly just recompile
C = just bugfixes, documentation tweaks, packaging, etc.

For example, a deprecation warning bumps B, but actually removing the 
deprecated functionality bumps A.


As for branching, if every release is tagged, and you want to apply a 
bugfix to release A.B.C, why not just create a maint-A.B branch or the 
like?  Delay creating branches until they are needed.  I wasn't seeing the 
need for the complex branching details.


I agree its nearing time for a "2.0" release; there has been talk of 
removing several now-deprecated functions and making other major changes 
(e.g. parallel testing).  Would it be possible to start collecting these 
into a preview/beta release and leave the "1.0" series with its current 
API and behaviors?  Just a thought.

I've done the build system for several projects I'm no longer associated 
with.  It would be nice if the people who inherited them don't have to 
rework them for a few more years.  A major version change (again, small 
numbers) might motivate distributions to keep both around for a while.


Hope that helps,
Daniel

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Dorland <eric <at> debian.org>
To: automake <at> gnu.org, bug-automake <at> gnu.org
Subject: Re: [IMPORTANT] A new versioning scheme for automake releases, and a
	new branching scheme for the Git repository
Date: Wed, 30 Jan 2013 16:07:09 -0500

[Message part 1 (text/plain, inline)]

* Stefano Lattarini (stefano.lattarini <at> gmail.com) 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 <eric <at> kuroneko.ca>
ICQ: #61138586, Jabber: hooty <at> jabber.com

[signature.asc (application/pgp-signature, inline)]

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake <at> gnu.org, bug-automake <at> gnu.org
Subject: Re: [IMPORTANT] A new versioning scheme for automake releases, and
	a new branching scheme for the Git repository
Date: Thu, 31 Jan 2013 13:17:12 +0100

On 01/30/2013 10:07 PM, Eric Dorland wrote:
>
> [SNIP PROPOSAL for new versioning scheme]
>
> I like it.
>
Glad to hear that :-)

> 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).
> 
> [SNIP PROPOSAL for new branching scheme]
>
>> 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.
>
While this move would have its merits, I think we should go ahead and
implement the new scheme right after the 1.13.2 release [1].  That is
because the current code in maint [2] already have some new features
and new warnings implemented, and that is exactly the situation where
a new minor version would be warranted according to the new proposed
scheme.

 [1] But not before we have reached a consensus on the proposal, of
    course; as Diego pointed out, this is not something to be rushed.

 [2] That would have become 1.13.3 with the old versioning scheme,
     and should become 1.14 with the new one.

> It makes it a cleaner break for people (aka Debian to some degree)
> who were relying on the old versioning scheme.
>

Thanks,
  Stefano

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
Cc: bug-automake <at> gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: [IMPORTANT] A new versioning scheme for automake releases, and
	a new branching scheme for the Git repository
Date: Thu, 31 Jan 2013 13:47:49 +0100

Hi Diego.

On 01/31/2013 12:46 PM, Diego Elio Pettenò wrote:
> On 28/01/2013 20:48, Stefano Lattarini wrote:
>> Feedback, opinions, objections?
> 
> First of all, I would like to hope that this is not going to be rushed
> through — it's an important and big change
>
Agreed.

> and I think having discussion about it with others might be a better
> idea.
>
But there is already such a discussion going on; see:

  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>

Or did you mean something else?

> One thing that worries me at first thought is how often do you expect a
> new major version to be out; once an year? twice an year? once every two
> years?
>
I think that, with the new freedom the minor versions would give us to
implement new features and do code optimization and refactoring, we could
aim to have a new major version every 18 or 24 months (this too should be
registered in HACKING).

> That rate is going to be the one thing that makes or breaks it
> from an automake consumer prospective I think.
>
Good point.

> Another thing that I think is important, that ties into the versioning
> scheme even though it's not really part of it would be to make two
> things cleaner:
> 
>  - what in Gentoo we call "slotting": i.e. the ability to install
> multiple automake versions in parallel; we have our own wrapper scripts
> maintained by Mike Frysinger, I think they were originally imported from
> Mandriva; I'm pretty sure other distributions have other similar
> wrappers... if instead of everybody having our own, we had a single
> maintained tool for the job, that would probably be a nice thing; while
> adding a suffix to the build solves most of the collisions between
> automake versions, info manuals for instance do not get renamed;
>
Since the scripts, the data directories and the manual pages are already
versioned (with both major and minor version), adding support for versioned
info pages might be enough to solve this issue.  Then, we might even add a
new option to Automake's configure to ensure only versioned stuff is
installed (that is, no 'bin/automake' link to 'bin/automake-1.13', no
'man1/automake.1' manapge containing ".so man1/automake-1.13.1", etc),
if that can make packagers' life even simpler.  Patches in these direction
would be welcome (I don't know when and if I'm going to write them myself,
sorry).

>  - ability for a configure script to check for automake version;
>
Isn't it too late to check for that at configure runtime?  You probably
want some m4 macro that let you discriminate between different versions
at automake/autoconf runtime, right?  (Your further elaboration below
seem to imply that the answer to this question is "yes").

> yes I know it's not the usually-proposed method to deal with it, but most
> projects would like to have something like that at this point. Otherwise
> we end up with m4_ifdef hacks that are just that: hacks.
> Especially if moving in the direction of multiple major versions, there
> are packages that would like to have their build system re-buildable on
> RHEL5 as well the latest Debian or Gentoo, and then they'll end up with
> nasty hacks, or requiring an older automake version and hope it doesn't
> cause other issues. Having a way to test whether we're running automake
> X.Y or later would be nice (and not just export the version value or
> people will mess up the test for "2.1", I've seen that happen too often
> for GCC or BerkDB).
> 
This might be a useful enhancement.  Does Autoconf offer enough pre-canned
macros to compare version numbers at runtime?  It seems it does [1], so it
might be enough to add a new automake-provided macro, modelled on the
autoconf-provided 'AC_AUTOCONF_VERSION' [2], that defines the current
Automake version.  AM_AUTOMAKE_VERSION sounds like the natural name...
But see below.

 [1] http://www.gnu.org/software/autoconf/manual/autoconf.html#m4_005fversion_005fcompare
 [2] http://www.gnu.org/software/autoconf/manual/autoconf.html#Versioning

Unfortunately, the 'AM_AUTOMAKE_VERSION' name is already taken for another
macro:

  $ cd src/automake
  $ cat m4/amversion.m4
  ...
  # AM_AUTOMAKE_VERSION(VERSION)
  # ----------------------------
  # Automake X.Y traces this macro to ensure aclocal.m4 has been
  # generated from the m4 files accompanying Automake X.Y.
  # (This private macro should not be called outside this file.)
  AC_DEFUN([AM_AUTOMAKE_VERSION],
  [am__api_version='1.13a'
  dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
  dnl require some minimum version.  Point them to the right macro.
  m4_if([$1], [1.13a], [],
        [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
  ])

However, that macro is private and only used internally (and cause a
fatal error if a user mistakenly tries to use it), so we might safely
rename it to something more appropriate, and free the name for the
new proposed usage.  Again, patches in this direction would be welcome.

Thanks,
  Stefano

Message #38 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Daniel Herring <dherring <at> tentpost.com>
Cc: 13578 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a	new branching scheme for the Git repository
Date: Thu, 31 Jan 2013 14:01:10 +0100

On 01/30/2013 04:30 AM, Daniel Herring wrote:
> On Mon, 28 Jan 2013, Stefano Lattarini wrote:
> 
>> Feedback, opinions, objections?
> 
> There was a lot to read, and I confess to not giving it full justice.
> 
> Others have already extolled the virtues of backwards compatibility.
> 
> 
> Regarding some "why" questions, here's the manual entry on how versioning
> is used today.
> 
> http://www.gnu.org/software/automake/manual/html_node/API-Versioning.html
>
And this is a good and valid policy, but one I have unfortunately broken
in practice during the last year or so.  This proposal should address that
breakage, restoring sane versioning semantics.

> 
> As far as I can tell, the current proposal boils down to "bump the major
> version more often".
>
The real issue is that the major version in currently being bumped already
in practice (big new features, backward-compatibility broken in some
respects), without this being reflected in the "true" version number
("hey, why have you broken backward-compatibility from 1.12 to 1.13?
What is wrong with you?").  And while this is mostly my fault, fixing
it will benefit everyone (in addition to healing my ego, of course :-)

> That can work, but I'm not quite sold on it.  I like when a major bump
> means "wake up and reread the docs before upgrading" and minor bumps
> mean "upgrade casually".
>
This is a good user-level approach that the new versioning scheme would
automatically encourage.

>  (and aggregate changes to minimize major bumps and make them more
> worthwhile)
> 
And similarly, this is a good developer-level approach that the new
versioning scheme would automatically encourage.

> Here are a couple "standards" for versioning.
> 
> http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
> http://semver.org/
> 
This last resource seems nice, but alas, adding support for "VERSION+BUILD"
development versions might prove a little more problematic than I'd like (of
course, parched are very very welcome).

> The general principle being A.B.C decodes to something easy like
> A = new API, breaking changes requiring human intervention
> B = same API, maybe with added options, mostly just recompile
> C = just bugfixes, documentation tweaks, packaging, etc.
> 
> For example, a deprecation warning bumps B, but actually removing
> the deprecated functionality bumps A.
>
Indeed.  Something that I have guiltily failed to do in the recent
Automake developement process.

> As for branching, if every release is tagged, and you want to
> apply a bugfix to release A.B.C, why not just create a maint-A.B
> branch or the like?
>
For older versions, that is indeed the sanest approach.  But I think
we should also accept the fact that the "last-released" minor version
is going to need mostly-frequent fixes (most of the will probably be
suggested by the work on the next minor release), so that having a
branch already and explicitly devoted to the purpose of implementing
such fixes is the best and simplest setup.

> Delay creating branches until they are needed.  I wasn't seeing the
> need for the complex branching details.
>
I don't think my "new" branching scheme is actually complex.  May I
ask what makes you label it as such?

> 
> I agree its nearing time for a "2.0" release; there has been talk
> of removing several now-deprecated functions and making other
> major changes (e.g. parallel testing).
>
Making the "parallel harness" a default has already been implemented
in 1.13; something I now quite regret not having delayed to a new
major version.

> Would it be possible to start collecting these into a preview/beta
> release and leave the "1.0" series with its current API and
> behaviors?  Just a thought.
>
Ideally, yes; but the time for a 2.0 will only come in a year or so
(as we want to give the existing non-fatal deprecation enough time
to brew, and there are also plans for several new minor versions in
the meantime).  So there is no need to hurry with previews etc.

> I've done the build system for several projects I'm no longer
> associated with.  It would be nice if the people who inherited
> them don't have to rework them for a few more years.  A major
> version change (again, small numbers) might motivate distributions
> to keep both around for a while.
>
Indeed; I hadn't thought about that explicitly when writing my
proposal, but you making a good point (and also offering a good
"between-the-line" suggestion: don't release new major versions
too often).

> 
> Hope that helps,
> Daniel

Thanks,
  Stefano

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: [IMPORTANT] A new versioning scheme for automake releases, and
	a new branching scheme for the Git repository
Date: Thu, 31 Jan 2013 12:46:08 +0100

On 28/01/2013 20:48, Stefano Lattarini wrote:
> Feedback, opinions, objections?

First of all, I would like to hope that this is not going to be rushed
through — it's an important and big change and I think having discussion
about it with others might be a better idea.

One thing that worries me at first thought is how often do you expect a
new major version to be out; once an year? twice an year? once every two
years? That rate is going to be the one thing that makes or breaks it
from an automake consumer prospective I think.

Another thing that I think is important, that ties into the versioning
scheme even though it's not really part of it would be to make two
things cleaner:

 - what in Gentoo we call "slotting": i.e. the ability to install
multiple automake versions in parallel; we have our own wrapper scripts
maintained by Mike Frysinger, I think they were originally imported from
Mandriva; I'm pretty sure other distributions have other similar
wrappers... if instead of everybody having our own, we had a single
maintained tool for the job, that would probably be a nice thing; while
adding a suffix to the build solves most of the collisions between
automake versions, info manuals for instance do not get renamed;

 - ability for a configure script to check for automake version; yes I
know it's not the usually-proposed method to deal with it, but most
projects would like to have something like that at this point. Otherwise
we end up with m4_ifdef hacks that are just that: hacks.
Especially if moving in the direction of multiple major versions, there
are packages that would like to have their build system re-buildable on
RHEL5 as well the latest Debian or Gentoo, and then they'll end up with
nasty hacks, or requiring an older automake version and hope it doesn't
cause other issues. Having a way to test whether we're running automake
X.Y or later would be nice (and not just export the version value or
people will mess up the test for "2.1", I've seen that happen too often
for GCC or BerkDB).

-- 
Diego Elio Pettenò — Flameeyes
flameeyes <at> flameeyes.eu — http://blog.flameeyes.eu/

Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: [IMPORTANT] A new versioning scheme for automake releases, and
	a new branching scheme for the Git repository
Date: Thu, 31 Jan 2013 15:58:36 +0100

On 31/01/2013 13:47, Stefano Lattarini wrote:
> But there is already such a discussion going on; see:
> 
>   <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
> 
> Or did you mean something else?

I would expect a more ... visible discussion. Honestly bugs are all nice
and shiny but I don't expect most of the automake consumers out there to
even know where to find them (debbugs is handy with the email interface,
but it's not exactly the nicest way to find and follow bugs, IMHO).

I'll probably write a blog post myself about it to get some attention to it.

> I think that, with the new freedom the minor versions would give us to
> implement new features and do code optimization and refactoring, we could
> aim to have a new major version every 18 or 24 months (this too should be
> registered in HACKING).

Okay that sounds reasonable. I would be more toward 24 than 18 — maybe
going for 18 to the next "beta"-quality automake, 24 to the final
release. Speaking of which I would suggest that we call X.0 the betas,
and suggest general usage only when X.1 is out...

> Since the scripts, the data directories and the manual pages are already
> versioned (with both major and minor version), adding support for versioned
> info pages might be enough to solve this issue.

To a point. While it allows the multiple installation it does not help
to solve the difference in multiple-automake changing between
distributions. My hope would be for something like that to get rid of
most of the "try-to-find-automake-version-X" logic in autogen.sh scripts
(the moment when autogen.sh scripts can finally DIAF, I'll rejoice).

> Then, we might even add a
> new option to Automake's configure to ensure only versioned stuff is
> installed (that is, no 'bin/automake' link to 'bin/automake-1.13', no
> 'man1/automake.1' manapge containing ".so man1/automake-1.13.1", etc),
> if that can make packagers' life even simpler.

Sounds like a good idea...

> Isn't it too late to check for that at configure runtime?  You probably
> want some m4 macro that let you discriminate between different versions
> at automake/autoconf runtime, right?  (Your further elaboration below
> seem to imply that the answer to this question is "yes").

Sorry I wasn't clear enough, I don't expect it to be found at
./configure time, but rather at autoconf time. So that one can decide
whether they want to use silent-rules, dist-xz, serial-tests and so on..

Don't assume that it's easy to install a newer automake on older systems
to work during development, because as I noted above, every distribution
has its way to wrap automake, and none that I know allows you a decent
way to integrate an user-provided version.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes <at> flameeyes.eu — http://blog.flameeyes.eu/

Message #47 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
Cc: 13578 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>,
	automake <at> gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Fri, 01 Feb 2013 06:58:14 +1100

Diego Elio Pettenò <flameeyes <at> flameeyes.eu> writes:
> Okay that sounds reasonable. I would be more toward 24 than 18 — maybe
> going for 18 to the next "beta"-quality automake, 24 to the final
> release. Speaking of which I would suggest that we call X.0 the betas,
> and suggest general usage only when X.1 is out...

IMHO, that seems like a great way to cause trouble for unsuspecting
users. (Anyone remember KDE4.0?) Can you expand on why you think it's a
good plan?

Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit
the ordering system for most package managers? Bonus points if it works
in asciibetical order, too.

-- Jack

Message #50 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
To: Jack Kelly <jack <at> jackkelly.name>
Cc: 13578 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>,
	automake <at> gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Fri, 01 Feb 2013 01:09:44 +0100

On 31/01/2013 20:58, Jack Kelly wrote:
> IMHO, that seems like a great way to cause trouble for unsuspecting
> users. (Anyone remember KDE4.0?) Can you expand on why you think it's a
> good plan?

Because unlike KDE, automake can put a big fat warning in the generated
configure that says "You're using a version unsuitable for production",
and then people would understand it much better.

KDE 4.0 was a screwup because there was no big fat warning, and users
insisted to have it. No user _asks_ for automake.

> Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit
> the ordering system for most package managers? Bonus points if it works
> in asciibetical order, too.

Good luck finding one. Gentoo would be fine with X.Y_betaZ — but I
honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y
for almost everything but autotools..

-- 
Diego Elio Pettenò — Flameeyes
flameeyes <at> flameeyes.eu — http://blog.flameeyes.eu/

Message #53 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
Cc: 13578 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>,
	automake <at> gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Fri, 01 Feb 2013 16:47:40 +1100

Diego Elio Pettenò <flameeyes <at> flameeyes.eu> writes:
> On 31/01/2013 20:58, Jack Kelly wrote:
>> IMHO, that seems like a great way to cause trouble for unsuspecting
>> users. (Anyone remember KDE4.0?) Can you expand on why you think it's a
>> good plan?
>
> Because unlike KDE, automake can put a big fat warning in the generated
> configure that says "You're using a version unsuitable for production",
> and then people would understand it much better.

Or at automake invocation time?

> KDE 4.0 was a screwup because there was no big fat warning, and users
> insisted to have it. No user _asks_ for automake.
>
>> Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit
>> the ordering system for most package managers? Bonus points if it works
>> in asciibetical order, too.
>
> Good luck finding one. Gentoo would be fine with X.Y_betaZ — but I
> honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y
> for almost everything but autotools..

Fair points. +1 to calling the betas "X.0".

-- Jack

Message #58 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jack Kelly <jack <at> jackkelly.name>
Cc: 13578 <at> debbugs.gnu.org,
	Diego Elio Pettenò <flameeyes <at> flameeyes.eu>,
	automake <at> gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Mon, 11 Feb 2013 15:54:57 +0100

Hi Diego, Jack, sorry for the late reply.

On 02/01/2013 06:47 AM, Jack Kelly wrote:
> Diego Elio Pettenò <flameeyes <at> flameeyes.eu> writes:
>> On 31/01/2013 20:58, Jack Kelly wrote:
>>> IMHO, that seems like a great way to cause trouble for unsuspecting
>>> users. (Anyone remember KDE4.0?) Can you expand on why you think it's a
>>> good plan?
>>
>> Because unlike KDE, automake can put a big fat warning in the generated
>> configure that says "You're using a version unsuitable for production",
>> and then people would understand it much better.
> 
> Or at automake invocation time?
> 
>> KDE 4.0 was a screwup because there was no big fat warning, and users
>> insisted to have it. No user _asks_ for automake.
>>
>>> Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit
>>> the ordering system for most package managers? Bonus points if it works
>>> in asciibetical order, too.
>>
>> Good luck finding one. Gentoo would be fine with X.Y_betaZ — but I
>> honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y
>> for almost everything but autotools..
> 
> Fair points. +1 to calling the betas "X.0".
> 
But what if we want to have multiple betas for, say, Automake 1.14?  Today,
we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
you are proposing?

As for the naming scheme for alpha/beta versions in Automake: I agree it is
suboptimal and a little confusing, its roots being likely based in the messy
1.4 -> 1.6 transition.  So far, it hasn't yet grated on me enough to motivate
me to try to improve it [1]; but if anyone wants to take a shot at that, be
my guest! (that will probably require some mail archive digging and "git blame"
invocations to see who introduced what for which reason).

  [1] In a way that is enough backward compatible, I mean.

Regards,
  Stefano

Message #61 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>, 
	Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Mon, 11 Feb 2013 16:00:34 +0100

On 11/02/2013 15:54, Stefano Lattarini wrote:
> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
> you are proposing?

Given that 1.12.0 was "not really final release", and 1.13.0 _and_ .1
were "not really final releases", I would suggest calling the first beta
as 1.14.0 with the big fat warning, then everybody's satisfied (no
missing features, for instance), it rolls as 1.14.4 (say) "really final
release".

This should be more or less equivalent to Apache's versioning, and leads
to decency, I'd say.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes <at> flameeyes.eu — http://blog.flameeyes.eu/

Message #64 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: automake <at> gnu.org, Jack Kelly <jack <at> jackkelly.name>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 08:50:59 +0900

Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
> you are proposing?

There's always 1.14.0.1, ...

Or the widely used in FOSS 1.13.99...
[sometimes they start at "90", to leave room for updates, but I suppose
you could always just use .99.1, .99.2, ...]

-miles

-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Message #67 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Miles Bader <miles <at> gnu.org>
Cc: automake <at> gnu.org, Jack Kelly <jack <at> jackkelly.name>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 09:06:09 +0100

Hi Miles.

On 02/12/2013 12:50 AM, Miles Bader wrote:
> Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
>> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
>> you are proposing?
> 
> There's always 1.14.0.1, ...
>
Yuck; the new versioning scheme is done exactly to avoid that kind
of overly long version numbers -- otherwise, we could just have
1.13.1.1 as bug-fixing release, 1.13.2 as new minor release, and
1.14 as new major release.  But if that leading "1" is going to
remain unchanged anyway, what is the point of keeping it?  It's
just "visual noise" IMO.

(In addition, the current version-checking code in Automake only
grasps version numbers with at most three numbers).

> Or the widely used in FOSS 1.13.99...
> [sometimes they start at "90", to leave room for updates,
>
This might work.  But see below.

> but I suppose you could always just use .99.1, .99.2, ...]
>
(No, because, as said above, I don't want to have version numbers
with four or more components)

Anyway, before changing the current naming scheme for beta versions,
we'd need some numbers about which the most widespread naming
schemes are, and weight their advantages and disadvantages w.r.t.
our "workflow"; we don't want to trade the current naming scheme
for another that is only marginally more popular, or for a one that
will give use a new and bigger set of problems down the road.

Thanks,
  Stefano

Message #70 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
Cc: 13578 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 09:26:01 +0100

On 02/11/2013 04:00 PM, Diego Elio Pettenò wrote:
> On 11/02/2013 15:54, Stefano Lattarini wrote:
>> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
>> you are proposing?
> 
> Given that 1.12.0 was "not really final release",
>
Why not?

> and 1.13.0 _and_ .1 were "not really final releases",
>
This is true, but is only due to the fact that I released them with
too much haste, without giving time for proper testing.  IOW, this
debacle has been a fault of mine, not of the naming scheme.

> I would suggest calling the first beta as 1.14.0 with the big fat
> warning,
>
I don't see any need for this; everyone knows that a new major release
is more likely to contain bugs and rough edges.  (OTOH, this is not
excuse to be sloppy and hastily in the release process as I've been
for 1.13; but avoiding repeating the mistake in the future will only
require more care and attention from the maintainer, and not a change
of policy).

> then everybody's satisfied (no missing features, for instance),
> it rolls as 1.14.4 (say) "really final release".
>
> This should be more or less equivalent to Apache's versioning,
>
Any link about this?  The info I found on Google doesn't seem very
helpful nor relevant.

> and leads to decency, I'd say.
> 

Thanks,
  Stefano

Message #73 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, Jack Kelly <jack <at> jackkelly.name>,
	13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 17:25:45 +0900

2013/2/12 Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>>> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
>>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
>>> you are proposing?
>>
>> There's always 1.14.0.1, ...
>>
> Yuck; the new versioning scheme is done exactly to avoid that kind
> of overly long version numbers

Well, I agree in general that too many components is yucky, but keep
in mind that these _aren't releases_, so assigning them "awkward"
version numbers doesn't really seem all that annoying.  These really
aren't part of the historical record.  The existing naming scheme for
betas does the same thing (uses "weird" version numbers), but is
problematic because it's not mechanically consistent with "ordinary"
version numbers (and so screws up cases such as packaging software).

I do agree that removing the leading "1." might be a good idea if it's
meaningless in practice.  Linux's similar action was good.

-miles

--
Cat is power.  Cat is peace.

Message #76 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Miles Bader <miles <at> gnu.org>
Cc: Automake List <automake <at> gnu.org>, Jack Kelly <jack <at> jackkelly.name>,
	13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 09:38:03 +0100

On 02/12/2013 09:25 AM, Miles Bader wrote:
> 2013/2/12 Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>>>> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
>>>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
>>>> you are proposing?
>>>
>>> There's always 1.14.0.1, ...
>>>
>> Yuck; the new versioning scheme is done exactly to avoid that kind
>> of overly long version numbers
> 
> Well, I agree in general that too many components is yucky, but keep
> in mind that these _aren't releases_, so assigning them "awkward"
> version numbers doesn't really seem all that annoying.  These really
> aren't part of the historical record.  The existing naming scheme for
> betas does the same thing (uses "weird" version numbers), but is
> problematic because it's not mechanically consistent with "ordinary"
> version numbers (and so screws up cases such as packaging software).
>
Mostly fair points; but the biggest issue with this proposal (not
sure why I didn't think of it before, sorry) is that it is not at
all clear that a version like "1.13.0.1" is supposed to be a beta
release.  People will easily mistake it for a stable release.  OK,
we can add warnings and info and whatnot in the manual and homepage
of automake about our unusual versioning scheme, but how many people
will read them?  And in the end, even those who do will likely be
just annoyed by the fact that we are trying to be clever and invent
a new versioining scheme incompatible with every other existing one.

No, if we want to change the versioning scheme for beta and rc
versions, we want the new scheme to be already used and well known.

> I do agree that removing the leading "1." might be a good idea if it's
> meaningless in practice.  Linux's similar action was good.
> 
> -miles
> 
> --
> Cat is power.  Cat is peace.

Thanks,
  Stefano

Message #79 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, Jack Kelly <jack <at> jackkelly.name>,
	13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 17:50:01 +0900

2013/2/12 Stefano Lattarini <stefano.lattarini <at> gmail.com>:
> Mostly fair points; but the biggest issue with this proposal (not
> sure why I didn't think of it before, sorry) is that it is not at
> all clear that a version like "1.13.0.1" is supposed to be a beta
> release.  People will easily mistake it for a stable release.

How about this:  pick whatever scheme you like for other reasons, and
then add "-beta" to those version numbers.  In other words, a purely
informational suffix, which is not actually necessary for version
sorting...

(note that the "a", "b", etc, suffixes have the same issue)

-miles

-- 
Cat is power.  Cat is peace.

Message #82 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13578 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 16:15:03 +0100

On 12/02/2013 09:26, Stefano Lattarini wrote:
>> Given that 1.12.0 was "not really final release",
>>
> Why not?

AM_PROG_MKDIR_P.

> This is true, but is only due to the fact that I released them with
> too much haste, without giving time for proper testing.  IOW, this
> debacle has been a fault of mine, not of the naming scheme.

True, but it shows a pattern: most people (even developers who get
involved in the process, such as Paolo) do not even look at the beta
versions..

> I don't see any need for this; everyone knows that a new major release
> is more likely to contain bugs and rough edges.  (OTOH, this is not
> excuse to be sloppy and hastily in the release process as I've been
> for 1.13; but avoiding repeating the mistake in the future will only
> require more care and attention from the maintainer, and not a change
> of policy).

True, but a new beta also is also more likely to contain bugs and rough
edges... so it's basically the same thing, thus why I'm saying that it
should just be the same. Put out the new major at "not stable yet", try
it out all around, then make a release to call it stable.

> Any link about this?  The info I found on Google doesn't seem very
> helpful nor relevant.

I'm afraid I don't have anything that Google wouldn't have. But at least
for 2.2, it was declared stable much later than ".0" if I'm not
mistaken. Basically, it would be like making policy that the new major
branch is not stable until we say it is.. which is really what we need.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes <at> flameeyes.eu — http://blog.flameeyes.eu/

Message #85 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Herring <dherring <at> tentpost.com>
To: 13578 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 11:36:20 -0500 (EST)

I like the -alpha/-beta/-rcN markings.  As someone who often tracks 
cutting-edge stuff, it is nice to have a clear indicator of how stable the 
author things something is.  This info helps the user do a quick 
cost/benefit estimate when deciding what version to use today.

- Daniel

Message #88 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
Cc: 13578 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 17:44:06 +0100

On 02/12/2013 04:15 PM, Diego Elio Pettenò wrote:
> On 12/02/2013 09:26, Stefano Lattarini wrote:
>>> Given that 1.12.0 was "not really final release",
>>>
>> Why not?
> 
> AM_PROG_MKDIR_P.
>
Ah, right.  I had forgot about that (selective memory? A dangerous
thing).

>> This is true, but is only due to the fact that I released them with
>> too much haste, without giving time for proper testing.  IOW, this
>> debacle has been a fault of mine, not of the naming scheme.
> 
> True, but it shows a pattern: most people (even developers who get
> involved in the process, such as Paolo) do not even look at the beta
> versions..
>
That is not something automake can do anything about.  Releasing
beta versions whose version numbers suggests they are actually
stable versions is a solution worse than the problem.  But you might
correctly point out that, due to lack of proper testing, this is
already what we are doing right now (albeit not by choice); so the
issue becomes at this point a documentation issue (that is, we should
find a way to inform the users that early stable versions of new major
releases might turn out to be lamentably unstable in practice, if
nobody has given the betas proper testing).  See again below.

>> I don't see any need for this; everyone knows that a new major release
>> is more likely to contain bugs and rough edges.  (OTOH, this is not
>> excuse to be sloppy and hastily in the release process as I've been
>> for 1.13; but avoiding repeating the mistake in the future will only
>> require more care and attention from the maintainer, and not a change
>> of policy).
> 
> True, but a new beta also is also more likely to contain bugs and rough
> edges... so it's basically the same thing, thus why I'm saying that it
> should just be the same. Put out the new major at "not stable yet", try
> it out all around, then make a release to call it stable.
>
This sounds sensible, but I think it should be done in addition to the
usual release of "classic" beta versions (with the hope that someone
will get to testing them eventually).  And if we agree on this approach,
the only required change would be a new section about this versioning
and stability issues in the Automake manual (and/or in the Autotools
Mythbuster guide).  As usual, patches are welcome (this is not really
my itch).

>> Any link about this?  The info I found on Google doesn't seem very
>> helpful nor relevant.
> 
> I'm afraid I don't have anything that Google wouldn't have. But at least
> for 2.2, it was declared stable much later than ".0" if I'm not
> mistaken.
>
That happened with Python as well, and I guess with many other softwares
who did a major version bump with non-trivial backward incompatibilities.

> Basically, it would be like making policy that the new major
> branch is not stable until we say it is.. which is really what we need.
> 
Ah, ok, so in the end you already agree that this is a "documentation"
issue rather than a versioning one.  Please correct me if I'm wrong!

Thanks,
  Stefano

Message #91 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Vincent Torri <vincent.torri <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org,
	Jack Kelly <jack <at> jackkelly.name>, Miles Bader <miles <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 09:42:31 +0100

On Tue, Feb 12, 2013 at 9:38 AM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> On 02/12/2013 09:25 AM, Miles Bader wrote:
>> 2013/2/12 Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>>>>> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
>>>>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
>>>>> you are proposing?
>>>>
>>>> There's always 1.14.0.1, ...
>>>>
>>> Yuck; the new versioning scheme is done exactly to avoid that kind
>>> of overly long version numbers
>>
>> Well, I agree in general that too many components is yucky, but keep
>> in mind that these _aren't releases_, so assigning them "awkward"
>> version numbers doesn't really seem all that annoying.  These really
>> aren't part of the historical record.  The existing naming scheme for
>> betas does the same thing (uses "weird" version numbers), but is
>> problematic because it's not mechanically consistent with "ordinary"
>> version numbers (and so screws up cases such as packaging software).
>>
> Mostly fair points; but the biggest issue with this proposal (not
> sure why I didn't think of it before, sorry) is that it is not at
> all clear that a version like "1.13.0.1" is supposed to be a beta
> release.  People will easily mistake it for a stable release.  OK,
> we can add warnings and info and whatnot in the manual and homepage
> of automake about our unusual versioning scheme, but how many people
> will read them?  And in the end, even those who do will likely be
> just annoyed by the fact that we are trying to be clever and invent
> a new versioining scheme incompatible with every other existing one.
>
> No, if we want to change the versioning scheme for beta and rc
> versions, we want the new scheme to be already used and well known.

in our project, we append _beta and _rc (or _rc1, _rc2 etc...) for
beta and release candidate. It's sufficiently explicit. For example,
1.14.0_beta

Vincent Torri

Message #94 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13578 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 18:50:29 +0100

On 12/02/2013 17:44, Stefano Lattarini wrote:
> Ah, ok, so in the end you already agree that this is a "documentation"
> issue rather than a versioning one.  Please correct me if I'm wrong!

I guess it's a matter of perception.

I honestly don't see the point of beta software if nobody's using it, as
it would just actually be an alpha for the beta (.0/.1 releases) which
then becomes stable (.2+ — sometimes).

If we go with a new major version we could have:

2.0.x -> new major, testing branch (let's not call it beta!), all fine
but it throws a huge warning at runtime that the branch is not finalized
yet and thus that it should not be used for distributed software

2.1.x -> new major, stable branch, micro versions for bugfix only

2.2.x -> new major, new features branch, introduces deprecation warnings
for features leaving in 3.0, possibly some opt-in versions of features
becoming standard in 3.0.

_If needed_ only:

2.90.x -> experimental branch for the upcoming 3.0 testing branch

-- 
Diego Elio Pettenò — Flameeyes
flameeyes <at> flameeyes.eu — http://blog.flameeyes.eu/

Message #97 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Diego Elio Pettenò <flameeyes <at> flameeyes.eu>
Cc: 13578 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Wed, 13 Feb 2013 19:20:06 +0100

Hi Diego.

On 02/12/2013 06:50 PM, Diego Elio Pettenò wrote:
> On 12/02/2013 17:44, Stefano Lattarini wrote:
>> Ah, ok, so in the end you already agree that this is a "documentation"
>> issue rather than a versioning one.  Please correct me if I'm wrong!
> 
> I guess it's a matter of perception.
> 
> I honestly don't see the point of beta software if nobody's using it, as
> it would just actually be an alpha for the beta (.0/.1 releases) which
> then becomes stable (.2+ — sometimes).
> 
> If we go with a new major version we could have:
> 
> 2.0.x -> new major, testing branch (let's not call it beta!), all fine
> but it throws a huge warning at runtime that the branch is not finalized
> yet and thus that it should not be used for distributed software
> 
> 2.1.x -> new major, stable branch, micro versions for bugfix only
> 
> 2.2.x -> new major, new features branch, introduces deprecation warnings
> for features leaving in 3.0, possibly some opt-in versions of features
> becoming standard in 3.0.
> 
> _If needed_ only:
> 
> 2.90.x -> experimental branch for the upcoming 3.0 testing branch
> 
The scheme you are proposing seems sensible to me.  Anyway, it is an
*extension* to my new proposed versioning/branching scheme, so we
don't have to decide on its adoption right away -- we can switch to
my proposed scheme first, and then refine/enhance it with your
proposal, if nobody objects.  OK?

Thanks,
  Stefano

Message #100 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake <at> gnu.org, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Wed, 13 Feb 2013 19:39:25 +0100

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

Message #103 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake <at> gnu.org, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Sun, 17 Feb 2013 15:57:45 +0100

On 02/13/2013 07:39 PM, Stefano Lattarini wrote:
>
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
>
> 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.
> 
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.

Thanks,
  Stefano

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----


From 97aaf121e92767dc06385d020dd30cdfaa86126f Mon Sep 17 00:00:00 2001
Message-Id: <97aaf121e92767dc06385d020dd30cdfaa86126f.1361111789.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Sun, 17 Feb 2013 10:25:29 +0100
Subject: [PATCH] describe new versioning and branching scheme, and adjust to it

See discussion about automake bug#13578 for more details and background.

Basically, for the versioning scheme:

  - micro versions only for bug and regression fixing;
  - minor versions for new backward-compatible features, and new
    non-fatal deprecations;
  - major versions for backward-incompatibilities, complex new
    features, and major refactoring.

And for the git branching scheme:

  + branch 'next' is for the upcoming major version;
  + branch 'master' is now for the upcoming minor version;
  + branch 'maint' is for the upcoming micro (bug-fixing) version;
  + the merging hierarchy is: 'maint' -> 'master' -> 'next'.

* HACKING (Automake versioning and compatibility scheme): New.
(Working with git): Adjust.
* NEWS: Update and fix.
* aclocal.in: Adjust some "FIXME" messages.
* automake.in: Likewise.
* m4/mkdirp.m4: Likewise.
* t/aclocal-acdir.sh: Likewise.
* t/aclocal-macrodir.tap: Likewise.
* t/aclocal-macrodirs.tap: Likewise.
* lib/Automake/Options.pm: Likewise.
* m4/internal/ac-config-macro-dirs.m4: Likewise.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 HACKING                             | 100 +++++++++++++++++++++++++++++-------
 NEWS                                |  59 +++++++++++++++++----
 aclocal.in                          |   8 +--
 automake.in                         |  12 +++--
 lib/Automake/Options.pm             |   4 +-
 m4/internal/ac-config-macro-dirs.m4 |   2 +-
 m4/mkdirp.m4                        |   3 +-
 t/aclocal-acdir.sh                  |   2 +-
 t/aclocal-macrodir.tap              |   2 +-
 t/aclocal-macrodirs.tap             |   2 +-
 10 files changed, 150 insertions(+), 44 deletions(-)

diff --git a/HACKING b/HACKING
index c70143e..604bf67 100644
--- a/HACKING
+++ b/HACKING
@@ -93,6 +93,48 @@
   code without.

 ============================================================================
+= Automake versioning and compatibility scheme
+
+* There are three kinds of automake releases:
+
+    - new major releases (e.g., 2.0, 5.0)
+    - new minor releases (e.g., 1.14, 2.1)
+    - micro a.k.a. "bug-fixing" releases (e.g., 1.13.2, 2.0.1, 3.5.17).
+
+  A new major release should have the major version number bumped, and
+  the minor and micro version numbers reset to zero.  A new minor release
+  should have the major version number unchanged, the minor version number
+  bumped, and the micro version number reset to zero.  Finally, a new
+  micro version should have the major and minor version numbers unchanged,
+  and the micro version number bumped.
+
+  For example, the first minor version after 1.13.2 will be 1.14; the
+  first bug-fixing version after 1.14 that will be 1.14.1; the first
+  new major version after all such releases will be 2.0; the first
+  bug-fixing version after 2.0 will be 2.0.1; and a further bug-fixing
+  version after 2.0.1 will be 2.0.2.
+
+* Micro releases 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 by them.
+
+* Minor releases 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.
+
+* 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 and code cleanups.
+
+* For more information, refer to the extensive discussion associated
+  with automake bug#13578.
+
+============================================================================
 = Working with git

 * To regenerate dependent files created by aclocal and automake,
@@ -103,22 +145,43 @@
   latest stable version of Autoconf installed and available early
   in your PATH.

-* The Automake git tree currently carries two basic branches: 'master' for
-  the current development, and 'maint' for maintenance and bug fixes.  The
-  maint branch should be kept regularly merged into the master branch.
-  It is advisable to merge only after a set of related commits have been
-  applied, to avoid introducing too much noise in the history.
+* The Automake git tree currently carries three basic branches: 'maint',
+  'master' and 'next'.
+
+* The 'maint' branch, reserved to changes that should go into the next
+  micro release; so it will just see fixes for regressions, trivial
+  bugs, or documentation issues, and no "active" development whatsoever.
+  Since emergency regression-fixing or security releases could be cut
+  from this branch at any time, it should always be kept in a releasable
+  state.
+
+* The 'master' branch is where the development of the next minor release
+  takes place.  It should be kept in a stable, almost-releasable state,
+  to simplify testing and deploying of new minor version.  Note that
+  this is not a hard rule, and such "stability" is not expected to be
+  absolute (emergency releases are cut from maint anyway).
+
+* The 'next' branch is reserved for the development of the next major
+  release.  Experimenting a little here is OK, but don't let the branch
+  grow too unstable; if you need to do exploratory programming
+  or over-arching change, you should use a dedicated topic branch, and
+  only merge that back once it is reasonably stable.
+
+* The 'maint' branch should be kept regularly merged into the 'master'
+  branch, and the 'master' branch into the 'next' branch.  It is advisable
+  to merge only after a set of related commits have been applied, to avoid
+  introducing too much noise in the history.

 * There may be a number of longer-lived feature branches for new
   developments.  They should be based off of a common ancestor of all
   active branches to which the feature should or might be merged later.
-  in the future, we might introduce a special branch named 'next' that
-  may serve as common ground for feature merging and testing, should
-  they not yet be ready for master.

-* After a major release is done, the master branch is to be merged into
-  the maint branch, and then a "new" master branch created stemming
-  from the resulting commit.
+* After a new minor release is done, the 'master' branch is to be merged
+  into the 'maint' branch, and then a "new" 'master' branch created
+  stemming from the resulting commit.
+  Similarly, after a new major release is done, the 'next' branch is to
+  be merged into both the 'master' and 'maint' branch, and then "new"
+  'master' and 'next' branches created stemming from the resulting commit.

 * When fixing a bug (especially a long-standing one), it may be useful
   to commit the fix to a new temporary branch based off the commit that
@@ -126,15 +189,14 @@
   the active branches descending from the buggy commit.  This offers a
   simple way to fix the bug consistently and effectively.

-* For merges from branches other than maint, prefer 'git merge --log' over
-  plain 'git merge', so that a later 'git log' gives an indication of which
-  actual patches were merged even when they don't appear early in the list.
+* For merges, prefer 'git merge --log' over plain 'git merge', so that
+  a later 'git log' gives an indication of which actual patches were
+  merged even when they don't appear early in the list.

-* master and release branches should not be rewound, i.e., should always
-  fast-forward, except maybe for privacy issues.  The maint branch should not
-  be rewound except maybe after retiring a release branch or a new stable
-  release.  For next, and for feature branches, the announcement for the
-  branch should document rewinding policy.
+* The 'next', 'master' and 'maint' branches should not be rewound, i.e.,
+  should always fast-forward, except maybe for privacy issues.  For
+  feature branches, the announcement for the branch should document
+  the rewinding policy.

 ============================================================================
 = Writing a good commit message
diff --git a/NEWS b/NEWS
index f9a1fb1..1ea9fa6 100644
--- a/NEWS
+++ b/NEWS
@@ -1,22 +1,59 @@
-New in 1.13.2:
+* WARNING: New versioning scheme for Automake.
+
+  - Starting with this version onward, Automake will use an update and
+    more rational versioning scheme, one that will allow users to know
+    which kind of changes can be expected from a new version, based on
+    its version number.
+
+    + Micro versions (e.g., 1.13.3, 2.0.1, 3.2.8) will introduce only
+      documentation updates and bug and regression fixes; they will
+      not introduce new features, nor any backward-incompatibility (any
+      such incompatibility would be considered a bug, to be fixed with
+      a further  micro release).
+
+    + Minor versions (e.g., 1.14, 2.1) can introduce new backward
+      compatible features; the only backward-incompatibilities allowed
+      in such a release are new *non-fatal* deprecations and warnings,
+      and possibly fixes for old or non-trivial bugs (or even inefficient
+      behaviours) that could unfortunately have been seen, and used, by
+      some developers as "corner case features".  This kind of fixes
+      should hopefully be quite rare.
+
+    + Major versions (now expected to be released every 18 or 24 months,
+      and not more often) can introduce new big features (possibly with
+      rough edges and not-fully-stabilized APIs), removal of deprecated
+      features, backward-incompatible changes of behaviour, and possibly
+      major refactorings (that, while ideally transparent to the user,
+      could introduce new bugs).  Incompatibilities should however not
+      be introduced gratuitously and abruptly; a proper deprecation path
+      should be duly implemented in the preceding minor releases.
+
+  - According to this new scheme, the next major version of Automake
+    (the one that has until now been labelled as '1.14') will actually
+    become "Automake 2.0".  Automake 1.14 will be the next minor version,
+    which will introduce new features and deprecation, but no backward
+    incompatibility.
+
+  - See discussion about automake bug#13578 for more details and
+    background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>

 * WARNING: Future backward-incompatibilities!

-  - Automake 1.14 will require Autoconf 2.70 or later (which is still
+  - Automake 2.0 will require Autoconf 2.70 or later (which is still
     unreleased at the moment of writing, but is planned to be released
-    before Automake 1.14 is).
+    before Automake 2.0 is).

-  - Automake 1.14 will drop support for the long-deprecated 'configure.in'
+  - Automake 2.0 will drop support for the long-deprecated 'configure.in'
     name for the Autoconf input file.  You are advised to start using the
     recommended name 'configure.ac' instead, ASAP.

   - The ACLOCAL_AMFLAGS special make variable will be fully deprecated
-    in Automake 1.14 (where it will raise warnings in the "obsolete"
+    in Automake 2.0 (where it will raise warnings in the "obsolete"
     category).  You are advised to start relying on the new Automake
     support for AC_CONFIG_MACRO_DIRS instead (which was introduced in
     Automake 1.13).

-  - Automake 1.14 will remove support for automatic dependency tracking
+  - Automake 2.0 will remove support for automatic dependency tracking
     with the SGI C/C++ compilers on IRIX.  The SGI depmode has been
     reported broken "in the wild" already, and we don't think investing
     time in debugging and fixing is worthwhile, especially considering
@@ -30,16 +67,20 @@ New in 1.13.2:
     modern Windows versions will continue to be fully supported.

   - Automake-provided scripts and makefile recipes might (finally!)
-    start assuming a POSIX shell in Automake 1.14.
+    start assuming a POSIX shell in Automake 2.0.

-  - Starting from Automake 1.14, third-party m4 files located in the
+  - Starting from Automake 2.0, third-party m4 files located in the
     system-wide aclocal directory, as well as in any directory listed
     in the ACLOCAL_PATH environment variable, will take precedence
     over "built-in" Automake macros.  For example (assuming Automake
     is installed in the /usr/local hierarchy), a definition of the
     AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
     should take precedence over the same-named automake-provided macro
-    (defined in '/usr/local/share/aclocal-1.14/vala.m4').
+    (defined in '/usr/local/share/aclocal-2.0/vala.m4').
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.2:

 * Obsolescent features:

diff --git a/aclocal.in b/aclocal.in
index b51c09d..82e9031 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -47,7 +47,7 @@ use File::Path ();
 # Some globals.

 # Support AC_CONFIG_MACRO_DIRS also with older autoconf.
-# FIXME: To be removed in Automake 1.14, once we can assume autoconf
+# FIXME: To be removed in Automake 2.0, once we can assume autoconf
 #        2.70 or later.
 # FIXME: keep in sync with 'internal/ac-config-macro-dirs.m4'.
 my $ac_config_macro_dirs_fallback =
@@ -744,7 +744,7 @@ sub trace_used_macros ()
   # a bug in option parsing code of autom4te 2.68 and earlier will cause
   # it to read standard input last, even if the "-" argument is specified
   # early.
-  # FIXME: To be removed in Automake 1.14, once we can assume autoconf
+  # FIXME: To be removed in Automake 2.0, once we can assume autoconf
   #        2.70 or later.
   $traces .= "$automake_includes[0]/internal/ac-config-macro-dirs.m4 ";

@@ -763,7 +763,7 @@ sub trace_used_macros ()
 		     'AC_CONFIG_MACRO_DIR_TRACE',
                      # FIXME: Tracing the next two macros is a hack for
                      # compatibility with older autoconf.  Remove this in
-                     # Automake 1.14, when we can assume Autoconf 2.70 or
+                     # Automake 2.0, when we can assume Autoconf 2.70 or
                      # later.
 		     'AC_CONFIG_MACRO_DIR',
 		     '_AM_CONFIG_MACRO_DIRS')),
@@ -820,7 +820,7 @@ sub trace_used_macros ()
   # FIXME: in Autoconf >= 2.70, AC_CONFIG_MACRO_DIR calls
   # AC_CONFIG_MACRO_DIR_TRACE behind the scenes, which could
   # leave unwanted duplicates in @ac_config_macro_dirs.
-  # Remove this in Automake 1.14, when we'll stop tracing
+  # Remove this in Automake 2.0, when we'll stop tracing
   # AC_CONFIG_MACRO_DIR explicitly.
   @ac_config_macro_dirs = uniq @ac_config_macro_dirs;

diff --git a/automake.in b/automake.in
index 9ed3507..0c2ab3d 100644
--- a/automake.in
+++ b/automake.in
@@ -2131,7 +2131,7 @@ sub handle_source_transform ($$$$%)
 	msg_var ('unsupported', $ext_var, $ext_var->name . " can assume at most one value")
 	  if $default_source_ext =~ /[\t ]/;
 	(my $default_source = $unxformed) =~ s,(\.[^./\\]*)?$,$default_source_ext,;
-	# TODO: Remove this backward-compatibility hack in Automake 1.14.
+	# TODO: Remove this backward-compatibility hack in Automake 2.0.
 	if ($old_default_source ne $default_source
 	    && !$ext_var
 	    && (rule $old_default_source
@@ -4146,8 +4146,8 @@ sub handle_configure ($$$@)
   # Distribute and define mkinstalldirs only if it is already present
   # in the package, for backward compatibility (some people may still
   # use $(mkinstalldirs)).
-  # TODO: start warning about this in Automake 1.13.2, and have
-  # TODO: Automake 1.14 or 1.15 drop it (and the mkinstalldirs script
+  # TODO: start warning about this in Automake 1.14, and have
+  # TODO: Automake 2.0 drop it (and the mkinstalldirs script
   # TODO: as well).
   my $mkidpath = "$config_aux_dir/mkinstalldirs";
   if (-f $mkidpath)
@@ -5144,7 +5144,7 @@ sub scan_autoconf_traces ($)
 		AC_REQUIRE_AUX_FILE => 1,
 		AC_SUBST_TRACE => 1,
 		AM_AUTOMAKE_VERSION => 1,
-                AM_PROG_MKDIR_P => 0, # FIXME: to be removed in 1.14
+                AM_PROG_MKDIR_P => 0,
 		AM_CONDITIONAL => 2,
 		AM_EXTRA_RECURSIVE_TARGETS => 1,
 		AM_GNU_GETTEXT => 0,
@@ -5300,8 +5300,10 @@ sub scan_autoconf_traces ($)

 	  $seen_automake_version = 1;
 	}
-      elsif ($macro eq 'AM_PROG_MKDIR_P') # FIXME: to be removed in 1.14
+      elsif ($macro eq 'AM_PROG_MKDIR_P')
 	{
+          # FIXME: we are no longer going to remove this! adjust warning
+          # FIXME: message accordingly.
 	  msg 'obsolete', $where, <<'EOF';
 The 'AM_PROG_MKDIR_P' macro is deprecated, and will soon be removed.
 You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,
diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm
index 3674920..cfeb78e 100644
--- a/lib/Automake/Options.pm
+++ b/lib/Automake/Options.pm
@@ -315,7 +315,7 @@ sub _process_option_list (\%@)
         {
           set_strictness ($_);
         }
-      # TODO: Remove this special check in Automake 1.14 or 1.15.
+      # TODO: Remove this special check in Automake 3.0.
       elsif (/^(.*\/)?ansi2knr$/)
         {
           # Obsolete (and now removed) de-ANSI-fication support.
@@ -327,7 +327,7 @@ sub _process_option_list (\%@)
         {
           error $where, "support for Cygnus-style trees has been removed";
         }
-      # TODO: Remove this special check in Automake 1.14 or 1.15.
+      # TODO: Remove this special check in Automake 3.0.
       elsif ($_ eq 'dist-lzma')
         {
           error ($where, "support for lzma-compressed distribution " .
diff --git a/m4/internal/ac-config-macro-dirs.m4 b/m4/internal/ac-config-macro-dirs.m4
index 4ddcef3..2684883 100644
--- a/m4/internal/ac-config-macro-dirs.m4
+++ b/m4/internal/ac-config-macro-dirs.m4
@@ -1,5 +1,5 @@
 # Support AC_CONFIG_MACRO_DIRS with older autoconf.     -*- Autoconf -*-
-# FIXME: To be removed in Automake 1.14, once we can assume autoconf
+# FIXME: To be removed in Automake 2.0, once we can assume autoconf
 #        2.70 or later.
 # FIXME: keep in sync with the contents of the variable
 #        '$ac_config_macro_dirs_fallback' in aclocal.in.
diff --git a/m4/mkdirp.m4 b/m4/mkdirp.m4
index 68f44cb..0b90d2c 100644
--- a/m4/mkdirp.m4
+++ b/m4/mkdirp.m4
@@ -11,7 +11,8 @@
 AC_DEFUN([AM_PROG_MKDIR_P],
 [AC_PREREQ([2.60])dnl
 AC_REQUIRE([AC_PROG_MKDIR_P])dnl
-dnl FIXME to be removed in Automake 1.14.
+dnl FIXME we are no longer going to remove this! adjust warning
+dnl FIXME message accordingly.
 AC_DIAGNOSE([obsolete],
 [$0: this macro is deprecated, and will soon be removed.
 You should use the Autoconf-provided 'AC][_PROG_MKDIR_P' macro instead,
diff --git a/t/aclocal-acdir.sh b/t/aclocal-acdir.sh
index 7fbb27a..80eba31 100755
--- a/t/aclocal-acdir.sh
+++ b/t/aclocal-acdir.sh
@@ -21,7 +21,7 @@
 . test-init.sh

 mkdir am sys
-# FIXME: remove in Automake 1.14.
+# FIXME: remove in Automake 2.0
 mkdir am/internal
 : > am/internal/ac-config-macro-dirs.m4

diff --git a/t/aclocal-macrodir.tap b/t/aclocal-macrodir.tap
index 3c66e53..44af05f 100755
--- a/t/aclocal-macrodir.tap
+++ b/t/aclocal-macrodir.tap
@@ -174,7 +174,7 @@ test_end
 #---------------------------------------------------------------------------

 # Avoid spurious failures with pre-2.70 autoconf.
-# FIXME: remove this in automake 1.14, once we require Autoconf 2.70.
+# FIXME: remove this in automake 2.0, once we require Autoconf 2.70.
 if echo 'AC_INIT AC_CONFIG_MACRO_DIRS' | $AUTOCONF -o/dev/null -; then

   test_begin "AC_CONFIG_MACRO_DIR interaction with AC_REQUIRE"
diff --git a/t/aclocal-macrodirs.tap b/t/aclocal-macrodirs.tap
index 89e424d..ac594bb 100755
--- a/t/aclocal-macrodirs.tap
+++ b/t/aclocal-macrodirs.tap
@@ -373,7 +373,7 @@ test_end
 #---------------------------------------------------------------------------

 # Avoid spurious failures with pre-2.70 autoconf.
-# FIXME: remove this in automake 1.14, once we require Autoconf 2.70.
+# FIXME: remove this in automake 2.0, once we require Autoconf 2.70.
 if echo 'AC_INIT AC_CONFIG_MACRO_DIRS' | $AUTOCONF -o/dev/null -; then

   test_begin "AC_CONFIG_MACRO_DIRS interaction with AC_REQUIRE"
-- 
1.8.1.1.701.g02339dd

Message #106 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake <at> gnu.org, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Thu, 21 Feb 2013 15:32:14 +0100

On 02/17/2013 03:57 PM, Stefano Lattarini wrote:
> On 02/13/2013 07:39 PM, Stefano Lattarini wrote:
>>
>> Reference:
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
>>
>> 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.
>>
> 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.

Regards,
  Stefano

Message #109 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake <at> gnu.org, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake
	releases, and a new branching scheme for the Git repository
Date: Thu, 21 Feb 2013 16:06:43 +0100

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.
> 
And here is the follow-up to fix some left-over references to the older
versioning scheme in 'maint' (they were not present in 'branch-1.13.2').
Already pushed to 'maint'.

In a couple of days, I will proceed with this "branch moving":

   * branch-1.13.2 -> maint
   * maint -> master
   * master -> next

Regards,
  Stefano

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From d5f83b89cc4d2da9078669018877b3bac5c2fadc Mon Sep 17 00:00:00 2001
Message-Id: <d5f83b89cc4d2da9078669018877b3bac5c2fadc.1361458350.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Thu, 21 Feb 2013 15:52:22 +0100
Subject: [PATCH] maint: more adjustments to the new versioning scheme

This is a follow-up to commit 'v1.13.1b-11-g97aaf12'.

* automake.in: Adjust a comment.
* PLANS: Adjust several files in here.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 PLANS/obsolete-removed/am-prog-mkdir-p.txt |  8 +++-----
 PLANS/obsolete-removed/configure.in.txt    | 10 +++++-----
 PLANS/rm-f-without-args.txt                | 10 +++++-----
 PLANS/subdir-objects.txt                   | 10 +++++-----
 PLANS/texi/drop-split-info-files.txt       |  6 +++---
 automake.in                                |  2 +-
 6 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/PLANS/obsolete-removed/am-prog-mkdir-p.txt b/PLANS/obsolete-removed/am-prog-mkdir-p.txt
index d5b7695..20d5cf5 100644
--- a/PLANS/obsolete-removed/am-prog-mkdir-p.txt
+++ b/PLANS/obsolete-removed/am-prog-mkdir-p.txt
@@ -1,6 +1,4 @@
-The macro AM_PROG_MKDIR_P is no longer going to be removed in Automake 1.14
-(and in fact, any plan to remove it "evenatually" has been dropped as well).
-
+The macro AM_PROG_MKDIR_P is no longer going to be removed from Automake.
 Let's see a bit of history to understand why.

 I had already scheduled the removal of the long-deprecated AM_PROG_MKDR_P
@@ -46,14 +44,14 @@ out, and we lose.  That already happened in practice:
     <http://lists.gnu.org/archive/html/bug-grep/2013-01/msg00003.html>

 Moreover, while I might see it as not unreasonable to ask a developer
-using Automake 1.14 to also update Gettext to 1.18.2, that would not
+using Automake 2.0 to also update Gettext to 1.18.2, that would not
 be enough; in order for gettext to use the correct data files, that
 developer would have to update his configure.ac to read:

     AM_GNU_GETTEXT_VERSION([0.18.2])

 thus requiring *all* of his co-developers to install Gettext 1.18.2,
-even if they are still using, say, Automake 1.13.  Bad.
+even if they are still using, say, Automake 1.13 or 1.14.  Bad.

 So I decided to re-instate this macro as a simple alias for AC_PROG_MKDIR_P
 (plus a non-fatal runtime warning in the 'obsolete' category), and drop
diff --git a/PLANS/obsolete-removed/configure.in.txt b/PLANS/obsolete-removed/configure.in.txt
index baed853..180f92c 100644
--- a/PLANS/obsolete-removed/configure.in.txt
+++ b/PLANS/obsolete-removed/configure.in.txt
@@ -13,16 +13,16 @@ present in the development version of autoconf so far (scheduled to
 become Autoconf 2.70).  So ...


-For Automake 1.14
------------------
+For Automake 2.0
+----------------

 ... we have decided to wait until 2.70 is out before really removing
 'configure.in' support.  Since we plan to require Autoconf 2.70 in
-Automake 1.14 (so that we can remove the hacky code emulating
+Automake 2.0 (so that we can remove the hacky code emulating
 AC_CONFIG_MACRO_DIRS for older autoconf versions), we are quite sure
 that Autoconf will actually have started deprecating 'configure.in'
-by the time Automake 1.14 is released.
+by the time Automake 2.0 is released.

 Note that the removal of 'configure.in' has already been implemented
-in our master branch (from where the 1.14 release will be finally
+in our 'next' branch (from where the 2.0 release will be finally
 cut); see commits 'v1.13-17-gbff57c8' and 'v1.13-21-g7626e63'.
diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt
index 5362f98..918e049 100644
--- a/PLANS/rm-f-without-args.txt
+++ b/PLANS/rm-f-without-args.txt
@@ -21,20 +21,20 @@ the no-args "rm -f" usage is supported on the system configure is
 being run on; complain loudly if this is not the case, and tell the
 user to report the situation to us.

-For Automake 1.14
------------------
+For Automake 2.0
+----------------

 Make any failure in the configure-time probe check introduced by the
 previous point fatal; and in case of failure, also suggest to the user
 to install an older version of GNU coreutils to work around the
 limitation of his system (this version should be old enough not to
-be bootstrapped with Automake 1.14, otherwise the user will face a
+be bootstrapped with Automake 2.0, otherwise the user will face a
 bootstrapping catch-22).

 In all our recipes, start assuming "rm -f" with no argument is OK;
 simplify and de-uglify the recipes accordingly.

-For Automake 1.15
------------------
+For Automake 3.0
+----------------

 Remove the runtime probe altogether.
diff --git a/PLANS/subdir-objects.txt b/PLANS/subdir-objects.txt
index e4e6e25..8647403 100644
--- a/PLANS/subdir-objects.txt
+++ b/PLANS/subdir-objects.txt
@@ -2,7 +2,7 @@ Summary
 -------

 We want to make the behaviour currently enabled by the 'subdir-objects'
-the default one, and in fact the *only* one, in Automake 1.14.
+the default one, and in fact the *only* one, in Automake 2.0.
 See automake bug#13378: <http://debbugs.gnu.org/13351>.

 Details
@@ -38,8 +38,8 @@ C compilation rules mistakenly passed the "-c -o" options combination
 unconditionally (even to losing compiler) when the 'subdir-objects' was
 used but sources were only present in the top-level directory.

-TODO for automake 1.13.2
-------------------------
+TODO for automake 1.14
+----------------------

 Give a warning in the category 'unsupported' if the 'subdir-objects'
 option is not specified.  This should give the users enough forewarning
@@ -50,8 +50,8 @@ Be sure to avoid the warning when it would be irrelevant, i.e., if all
 source files sit in "current" directory (thanks to Peter Johansson for
 suggesting this).

-For automake 1.14
------------------
+For automake 2.0
+----------------

 Remove the copy & paste of Autoconf internals in our AC_PROG_CC rewrite
 See the first patch in the series:
diff --git a/PLANS/texi/drop-split-info-files.txt b/PLANS/texi/drop-split-info-files.txt
index 7084331..8b36ecb 100644
--- a/PLANS/texi/drop-split-info-files.txt
+++ b/PLANS/texi/drop-split-info-files.txt
@@ -1,7 +1,7 @@
-For automake 1.14
------------------
+For automake 2.0
+----------------

-We want to drop split info files in Automake 1.14.
+We want to drop split info files in Automake 2.0.
 See automake bug#13351: <http://debbugs.gnu.org/13351>.

 Basically, it has been confirmed that the original reason behind
diff --git a/automake.in b/automake.in
index 44d67b4..13811f7 100644
--- a/automake.in
+++ b/automake.in
@@ -1711,7 +1711,7 @@ sub handle_single_transform ($$$$$%)
                 }
               else
                 {
-                  # Since the next major version of automake (1.14) will
+                  # Since the next major version of automake (2.0) will
                   # make the behaviour so far only activated with the
                   # 'subdir-object' option mandatory, it's better if we
                   # start warning users not using that option.
-- 
1.8.1.1.754.gb3600c3

Message #114 received at 13578-done <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake <at> gnu.org, 13578-done <at> debbugs.gnu.org
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,
  Stefano

Message #117 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 13578 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: [IMPORTANT] Savannah issues
Date: Sat, 23 Feb 2013 19:06:14 +0100

On 02/23/2013 06:46 PM, Stefano Lattarini wrote:
> 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.
>
Damn, not really.  For some questionable reason, Savannah is rejecting
my non-fast-forward push to master even if I specify '--force', and
I cannot use the usual trick "delete the remote branch, then push the
local one to it" trick that I typically use to work around this
problem, since 'master' is the "current branch" of the remote
repository, and that cannot be deleted to avoid confusing "git clone".

For reference, this is the error message I got when I try to delete
master:

  remote: error: By default, deleting the current branch is denied, because the next
  remote: error: 'git clone' won't result in any file checked out, causing confusion.
  remote: error:
  remote: error: You can set 'receive.denyDeleteCurrent' configuration variable to
  remote: error: 'warn' or 'ignore' in the remote repository to allow deleting the
  remote: error: current branch, with or without a warning message.
  remote: error:
  remote: error: To squelch this message, you can set it to 'refuse'.
  remote: error: refusing to delete the current branch: refs/heads/master

So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN
INCONSISTENT STATE* (not broken, mind you, merely inconsistent with
our new declared policies), and should not be used until this issue
is resolved.

I don't have time to look into this presently, so I'd appreciate if
anyone could look into the issue (finding a way not have savannah
to reject non-fast-forward pushes would be enough).

Thanks, and sorry for the confusion,
  Stefano

Message #120 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Mon, 25 Feb 2013 09:14:08 +0100

On 2013-02-23 19:06, Stefano Lattarini wrote:
> On 02/23/2013 06:46 PM, Stefano Lattarini wrote:
>> On 02/21/2013 04:06 PM, Stefano Lattarini wrote:
>>> In a couple of days, I will proceed with this "branch moving":
>>>
>>>    * branch-1.13.2 -> maint
>>>    * maint -> master
>>>    * master -> next
>>>
>> Done.
>>
> Damn, not really.  For some questionable reason, Savannah is rejecting
> my non-fast-forward push to master even if I specify '--force', and
> I cannot use the usual trick "delete the remote branch, then push the
> local one to it" trick that I typically use to work around this
> problem, since 'master' is the "current branch" of the remote
> repository, and that cannot be deleted to avoid confusing "git clone".

I was not aware that those moves would be non-fast-forwards, and I
think this is bad bad bad. It's quite hostile to do non-fast-forwards
on branches as central as master and maint. And I think git/savannah
is rejecting them quite rightly!

master and maint have never been published as "rewindable", and it should
be correct to base new work on them. They should be left alone, IMHO.
You should have implemented this more gradually, such that next would
have taken its role directly, but maint and master should have been
allowed to grow into the correct branches once the relevant releases had
been made. Or even better, implement the change right after a major
release so that master and maint would have been correctly positioned
from the start.

I have a few single-commit local branches that I will simply have to
cherry-pick to the new world order. Or is there some better way to move
these branches after their base has been pulled from under them?
Hopefully there isn't some big chunk of unpublished work that will be
killed by these disruptive changes...

Cheers,
Peter

Message #123 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Mon, 25 Feb 2013 10:16:54 +0100

On 02/25/2013 09:14 AM, Peter Rosin wrote:
> On 2013-02-23 19:06, Stefano Lattarini wrote:
>> On 02/23/2013 06:46 PM, Stefano Lattarini wrote:
>>> On 02/21/2013 04:06 PM, Stefano Lattarini wrote:
>>>> In a couple of days, I will proceed with this "branch moving":
>>>>
>>>>    * branch-1.13.2 -> maint
>>>>    * maint -> master
>>>>    * master -> next
>>>>
>>> Done.
>>>
>> Damn, not really.  For some questionable reason, Savannah is rejecting
>> my non-fast-forward push to master even if I specify '--force', and
>> I cannot use the usual trick "delete the remote branch, then push the
>> local one to it" trick that I typically use to work around this
>> problem, since 'master' is the "current branch" of the remote
>> repository, and that cannot be deleted to avoid confusing "git clone".
> 
> I was not aware that those moves would be non-fast-forwards, and I
> think this is bad bad bad.
>
Note that the users can avoid branch-rewriting issues by renaming their
'master' to 'next' and their 'maint' to 'master' before pulling.  This
should probably be stated in a message (on list *and* on savannah news)
advertising the new versioning and branching scheme (message not yet
written; it will be once the current issue is sorted out).

> It's quite hostile to do non-fast-forwards
> on branches as central as master and maint. And I think git/savannah
> is rejecting them quite rightly!
>
Savannah is rejecting all non-fast-forward pushes (which I find annoying);
but it didn't prevent me from deleting and recreating maint, a change that
will still appear as a non-fast-forward to any clone of our repository.

The reason it doesn't allow me to delete master as well is that doing so
would prevent a "git clone" from checking out the sources of a freshly
cloned automake, which can be very confusing (and of course, git cannot
be aware of the fact that I intend to re-create 'master' just after
having deleted it).

> master and maint have never been published as "rewindable", and it should
> be correct to base new work on them. They should be left alone, IMHO.
>
Their content has been left alone in fact; it's their "name" that hasn't.

> You should have implemented this more gradually, such that next would
> have taken its role directly, but maint and master should have been
> allowed to grow into the correct branches once the relevant releases had
> been made.
>
This would give a very confusing interim period IMHO.

However, note that that we can still implement such a "gentler transition"
(for 'master' only) if you really want to, by using a new branch name
(maybe 'current' or 'devel') instead of 'master', keeping 'master' as a
temporary "alias" to 'next' until the 2.0 release (at which point all of
'maint', 'master' and 'next' will be fast-forwarded to the commit that
implements the 2.0 release).  I still prefer to pull this sore tooth out
right now, though.

> Or even better, implement the change right after a major
> release so that master and maint would have been correctly positioned
> from the start.
> 
> I have a few single-commit local branches that I will simply have to
> cherry-pick to the new world order.
>
No, just rebase them on the new name of the branch they were based on;
that is, if they were based on 'master', they are now to be considered
based on 'next', if they were based on 'maint', they are now to be
considered based on 'master', and if they were based on 'branch-1.13.2'
they are not to be considered based on 'maint'.

> Or is there some better way to move
> these branches after their base has been pulled from under them?
>
The good thing is that is has not been really pulled away, just *renamed*.

Remember that Git branches are just "movable tags" basically, so as long
as you have another "handle" referencing the same commit a branch points
to (be that a tag or another branch), nothing is lost by removing the
branch -- you are just removing a tag, not any "real" content.

> Hopefully there isn't some big chunk of unpublished work that will be
> killed by these disruptive changes...
>
No, there is not.  As said, no pre-existing commit has been dropped by
my planned renames.

HTH,
  Stefano

Message #126 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 13578 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: [IMPORTANT] Savannah issues
Date: Mon, 25 Feb 2013 14:40:37 +0100

On 02/23/2013 07:06 PM, Stefano Lattarini wrote:
>
>>> In a couple of days, I will proceed with this "branch moving":
>>>
>>>    * branch-1.13.2 -> maint
>>>    * maint -> master
>>>    * master -> next
>>>
>> Done.
>>
> Damn, not really.  For some questionable reason, Savannah is rejecting
> my non-fast-forward push to master even if I specify '--force', and
> I cannot use the usual trick "delete the remote branch, then push the
> local one to it" trick that I typically use to work around this
> problem, since 'master' is the "current branch" of the remote
> repository, and that cannot be deleted to avoid confusing "git clone".
> 
> So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN
> INCONSISTENT STATE* (not broken, mind you, merely inconsistent with
> our new declared policies), and should not be used until this issue
> is resolved.
> 
> I don't have time to look into this presently,
>
I had time today, so I submitted a Task in the Savannah interface:
<https://savannah.gnu.org/task/index.php?12497>

Regards,
  Stefano

Message #129 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: [IMPORTANT] Savannah issues
Date: Tue, 26 Feb 2013 07:28:45 +0900

Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
>>>>    * maint -> master
>>>>    * master -> next
>>>
>> Damn, not really.  For some questionable reason, Savannah is rejecting
>> my non-fast-forward push to master even if I specify '--force', and
>> I cannot use the usual trick "delete the remote branch, then push the
>> local one to it" trick that I typically use to work around this
>> problem, since 'master' is the "current branch" of the remote
>> repository, and that cannot be deleted to avoid confusing "git clone".
>> 
>> So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN
>> INCONSISTENT STATE* (not broken, mind you, merely inconsistent with
>> our new declared policies), and should not be used until this issue
>> is resolved.
>> 
>> I don't have time to look into this presently,
>>
> I had time today, so I submitted a Task in the Savannah interface:
> <https://savannah.gnu.org/task/index.php?12497>

What's the point of this renaming, anyway?

It doesn't seem to make any functional difference what the names of
the branches you use for dev sources and releases are -- and besides
being a practical problem, the scheme you've chosen doesn't follow
common git practice, so will be surprising/confusing to people...

-miles

-- 
You can hack anything you want, with TECO and DDT.

Message #132 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Miles Bader <miles <at> gnu.org>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: [IMPORTANT] Savannah issues
Date: Tue, 26 Feb 2013 00:07:22 +0100

On 02/25/2013 11:28 PM, Miles Bader wrote:
> Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
>>>>>    * maint -> master
>>>>>    * master -> next
>>>>
>>> Damn, not really.  For some questionable reason, Savannah is rejecting
>>> my non-fast-forward push to master even if I specify '--force', and
>>> I cannot use the usual trick "delete the remote branch, then push the
>>> local one to it" trick that I typically use to work around this
>>> problem, since 'master' is the "current branch" of the remote
>>> repository, and that cannot be deleted to avoid confusing "git clone".
>>>
>>> So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN
>>> INCONSISTENT STATE* (not broken, mind you, merely inconsistent with
>>> our new declared policies), and should not be used until this issue
>>> is resolved.
>>>
>>> I don't have time to look into this presently,
>>>
>> I had time today, so I submitted a Task in the Savannah interface:
>> <https://savannah.gnu.org/task/index.php?12497>
> 
> What's the point of this renaming, anyway?
>
The fact that the master branch, being in many ways "the default one"
in the Git world, is the one that is most visible and tested; so it
should be the one where the future minor releases (that we now pledge
to keep backward-compatible) are cut from.

> It doesn't seem to make any functional difference what the names of
> the branches you use for dev sources and releases are
>
Functional differences, no, strictly speaking.  Yet, when someone clones the
Automake repository, he has the 'master' branch checked out automatically
(apart for 'bare' clones, where no branch is checked out -- but that is a
different usage scenario).  And the automated Hydra builder checks the
master branch: <http://hydra.nixos.org/jobset/gnu/automake-master>.  And
there surely are many other situations where the 'master' branch is
handled in special ways, either technically or culturally.

 -- and besides
> being a practical problem, the scheme you've chosen doesn't follow
> common git practice,
>
How so?   If you are referring the practice of having 'next' as a test
bed for the features to be eventually merged into 'master', note that
is not an usual setup, but is only employed by the Git project itself
for its own repository; and while I admit it is an intelligent approach
that works quite well there, it only does so because of Git's large
developer base and very dedicated and very capable maintainer -- things
these that Automake lacks at present.

> so will be surprising/confusing to people...
>
Maybe to Git's developers, but I don't see many lurking in here ;-)

And anyway, even if that turns out to be the case, the solution would
not be to change the new policy for 'master', but to change name to
the 'next' branch.  And I'm not particularly attached to that name;
if anyone wants to suggest a better one, and manage to get a consensus
on it, I'm quite ready to rename accordingly.

Regards,
  Stefano

Message #135 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Tue, 26 Feb 2013 00:53:11 +0100

On 2013-02-25 10:16, Stefano Lattarini wrote:
> On 02/25/2013 09:14 AM, Peter Rosin wrote:
>> On 2013-02-23 19:06, Stefano Lattarini wrote:
>>> On 02/23/2013 06:46 PM, Stefano Lattarini wrote:
>>>> On 02/21/2013 04:06 PM, Stefano Lattarini wrote:
>>>>> In a couple of days, I will proceed with this "branch moving":
>>>>>
>>>>>    * branch-1.13.2 -> maint
>>>>>    * maint -> master
>>>>>    * master -> next
>>>>>
>>>> Done.
>>>>
>>> Damn, not really.  For some questionable reason, Savannah is rejecting
>>> my non-fast-forward push to master even if I specify '--force', and
>>> I cannot use the usual trick "delete the remote branch, then push the
>>> local one to it" trick that I typically use to work around this
>>> problem, since 'master' is the "current branch" of the remote
>>> repository, and that cannot be deleted to avoid confusing "git clone".
>>
>> I was not aware that those moves would be non-fast-forwards, and I
>> think this is bad bad bad.
>>
> Note that the users can avoid branch-rewriting issues by renaming their
> 'master' to 'next' and their 'maint' to 'master' before pulling.  This
> should probably be stated in a message (on list *and* on savannah news)
> advertising the new versioning and branching scheme (message not yet
> written; it will be once the current issue is sorted out).

Hiding stuff like that in some documentation or on a mailing list will
not help. You should make it *easy* for people to work on and contribute
to automake. Forcing everyone to do a bunch of silly boring renames
is not *easy*. It's an obstacle, and obstacles make people nervous
and uneasy. Not good, and no, you can't document it away.

>> It's quite hostile to do non-fast-forwards
>> on branches as central as master and maint. And I think git/savannah
>> is rejecting them quite rightly!
>>
> Savannah is rejecting all non-fast-forward pushes (which I find annoying);
> but it didn't prevent me from deleting and recreating maint, a change that
> will still appear as a non-fast-forward to any clone of our repository.
> 
> The reason it doesn't allow me to delete master as well is that doing so
> would prevent a "git clone" from checking out the sources of a freshly
> cloned automake, which can be very confusing (and of course, git cannot
> be aware of the fact that I intend to re-create 'master' just after
> having deleted it).

The reason is irrelevant. non-fast-forwards of central branches is evil.

>> master and maint have never been published as "rewindable", and it should
>> be correct to base new work on them. They should be left alone, IMHO.
>>
> Their content has been left alone in fact; it's their "name" that hasn't.
> 
>> You should have implemented this more gradually, such that next would
>> have taken its role directly, but maint and master should have been
>> allowed to grow into the correct branches once the relevant releases had
>> been made.
>>
> This would give a very confusing interim period IMHO.

Yes, confusing. Changes like this cause confusion.

> However, note that that we can still implement such a "gentler transition"
> (for 'master' only) if you really want to, by using a new branch name
> (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a
> temporary "alias" to 'next' until the 2.0 release (at which point all of
> 'maint', 'master' and 'next' will be fast-forwarded to the commit that
> implements the 2.0 release).  I still prefer to pull this sore tooth out
> right now, though.

So messy.

>> Or even better, implement the change right after a major
>> release so that master and maint would have been correctly positioned
>> from the start.
>>
>> I have a few single-commit local branches that I will simply have to
>> cherry-pick to the new world order.
>>
> No, just rebase them on the new name of the branch they were based on;
> that is, if they were based on 'master', they are now to be considered
> based on 'next', if they were based on 'maint', they are now to be
> considered based on 'master', and if they were based on 'branch-1.13.2'
> they are not to be considered based on 'maint'.

( s/are not to/are now to/ )

Yes, that works. But it is a nuisance.

>> Or is there some better way to move
>> these branches after their base has been pulled from under them?
>>
> The good thing is that is has not been really pulled away, just *renamed*.
> 
> Remember that Git branches are just "movable tags" basically, so as long
> as you have another "handle" referencing the same commit a branch points
> to (be that a tag or another branch), nothing is lost by removing the
> branch -- you are just removing a tag, not any "real" content.

Yes, but the "renames" are extremely surprising to a casual contributor.
What if someone has a few commits on, say maint, from before your rename.
This someone didn't bother to create a topic branch for these commits
for some reason. What happens when those local commits have been forgotten
and the new-world-order is pulled? A merge is attempted of the local commits
and the whole difference between old and new maint. That is likely to
result in a conflict. So, our imaginary dev restores the local maint and
puts the local commits on a topic branch and retries only to again see
a conflict when the pull is attempted. I bet the poor dev will not first
think that upstream has messed up, but that it is some local crap that is
happening. How much time will be wasted?

BTW, just to test this I did the perfectly valid (no local commits on
maint):

git checkout maint
git pull

And my repo is now in a mess with unresolved conflicts. This rename
is a mess. It is only clean for you, since it originated from you.
Everyone else will have to take about the same manual steps you
did in order to follow. Which is crappy and evil and will only work
for those of us who pay close attention to the mailing list/docs.
The poor sods with a git checkout as of last week but having no reason
to pull for some time will wonder what hit them when they actually do
pull.

Also, git history is fuubared. E.g. commit 0756a43c3a77
"Merge branch 'branch-1.13.2' into maint" is in fact no longer on maint.
How confusing is that?

>> Hopefully there isn't some big chunk of unpublished work that will be
>> killed by these disruptive changes...
>>
> No, there is not.  As said, no pre-existing commit has been dropped by
> my planned renames.

Message #138 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: [IMPORTANT] Savannah issues
Date: Tue, 26 Feb 2013 09:37:15 +0900

Just that by far the most common branch setup in git repos seems to be
using master as the "dev trunk", with releases, release candidates
(etc) on special branches.  There are often additional feature
branches for even more speculative changes, but master is generally
not really "safe," even if it's not the most dangerous branch.

So master tends to be a sort of "middle" state (between
release/release-candidate branches and speculative feature branches),
stuff that is slated for the next release, and has received review --
but may still have some bugs to be shaken out.  For complicated
long-term changes, people often do development on special feature
branches, but smaller and more straight-forward changes generally get
put into master directly.  Master branches break with some regularity.

If you're familiar with gcc's subversion repo setup, it's pretty
similar to this (with the subversion trunk being "master")

Git's own repo actually does this too.

Thanks,

-miles

-- 
Cat is power.  Cat is peace.

Message #141 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Tue, 26 Feb 2013 19:30:14 +0100

Hi Peter.

On 02/26/2013 12:53 AM, Peter Rosin wrote:
> On 2013-02-25 10:16, Stefano Lattarini wrote:
>
>>
>> Note that the users can avoid branch-rewriting issues by renaming their
>> 'master' to 'next' and their 'maint' to 'master' before pulling.  This
>> should probably be stated in a message (on list *and* on savannah news)
>> advertising the new versioning and branching scheme (message not yet
>> written; it will be once the current issue is sorted out).
> 
> Hiding stuff like that in some documentation or on a mailing list will
> not help. You should make it *easy* for people to work on and contribute
> to automake. Forcing everyone to do a bunch of silly boring renames
> is not *easy*. It's an obstacle, and obstacles make people nervous
> and uneasy. Not good, and no, you can't document it away.
>
You might have good points, and possibly even be completely right...
But I must ask, why didn't you step up during the lengthy discussion
about this change, nor objected during the delay (almost a week) that
was deliberately let pass between the decision and the implementation
-- precisely to let this kind of late objections to come out?  What is
the point of having such discussions in the first place, if people who
oppose a proposed change (maybe even on solid ground and with sound
reasons) only object *after* the change has been discussed, accepted
and implemented?

>>> It's quite hostile to do non-fast-forwards
>>> on branches as central as master and maint. And I think git/savannah
>>> is rejecting them quite rightly!
>>>
>> Savannah is rejecting all non-fast-forward pushes (which I find annoying);
>> but it didn't prevent me from deleting and recreating maint, a change that
>> will still appear as a non-fast-forward to any clone of our repository.
>>
>> The reason it doesn't allow me to delete master as well is that doing so
>> would prevent a "git clone" from checking out the sources of a freshly
>> cloned automake, which can be very confusing (and of course, git cannot
>> be aware of the fact that I intend to re-create 'master' just after
>> having deleted it).
> 
> The reason is irrelevant. non-fast-forwards of central branches is evil.
>
Mostly, yes.  This time, considering that no commits were actually being
dropped or rewritten, I believed it wasn't not that bad, and was IMHO
justified by the new improved versioning and branching scheme.

And while you *might* have changed my mind before (because you have
valid points, and maybe it would have better to err on the side of
safety), I have now already rewritten maint, so rather than messing
up by rewriting it again (to its old value, granted, but a rewrite
nonetheless) and reverting an already made decision (and made after
considerable discussion and not negligible efforts), I'd rather stuck
with the current minor "mess".

That said, if it turns out that I'm in minority in supporting such an
approach, then feel free to revert the maint rewrite [1] (and I'll drop
the planned master rewrite); I'm not here to forcibly impose my will
on the majority, at least not when the majority has good points or
valid concerns.

  [1] And rename the bug-fixing branch to something like 'fix'
      or 'micro', and adjust HACKING accordingly -- with a clear
      and explicative commit message.

Whatever the result will be, I'm starting to lose faith in the
usefulness of having lengthy discussion for controversial changes
beforehand; if we don't and I just go ahead with my idea, some (or
most) people will complain after the fact; if we do, and a consensus
is reached and implemented, some people still complain after the
fact.  Not a great situation, motivational-wise ...

>>> master and maint have never been published as "rewindable", and it should
>>> be correct to base new work on them. They should be left alone, IMHO.
>>>
>> Their content has been left alone in fact; it's their "name" that hasn't.
>>
>>> You should have implemented this more gradually, such that next would
>>> have taken its role directly, but maint and master should have been
>>> allowed to grow into the correct branches once the relevant releases had
>>> been made.
>>>
>> This would give a very confusing interim period IMHO.
> 
> Yes, confusing. Changes like this cause confusion.
> 
>> However, note that that we can still implement such a "gentler transition"
>> (for 'master' only) if you really want to, by using a new branch name
>> (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a
>> temporary "alias" to 'next' until the 2.0 release (at which point all of
>> 'maint', 'master' and 'next' will be fast-forwarded to the commit that
>> implements the 2.0 release).  I still prefer to pull this sore tooth out
>> right now, though.
> 
> So messy.
>
Indeed.  Better be consistent and rewrite 'master' too.

>>> Or even better, implement the change right after a major
>>> release so that master and maint would have been correctly positioned
>>> from the start.
>>>
>>> I have a few single-commit local branches that I will simply have to
>>> cherry-pick to the new world order.
>>>
>> No, just rebase them on the new name of the branch they were based on;
>> that is, if they were based on 'master', they are now to be considered
>> based on 'next', if they were based on 'maint', they are now to be
>> considered based on 'master', and if they were based on 'branch-1.13.2'
>> they are not to be considered based on 'maint'.
> 
> ( s/are not to/are now to/ )
>
Yes, sorry for the typo.

> Yes, that works. But it is a nuisance.
>
Yes, but an easily bearable one IMHO.

>>> Or is there some better way to move
>>> these branches after their base has been pulled from under them?
>>>
>> The good thing is that is has not been really pulled away, just *renamed*.
>>
>> Remember that Git branches are just "movable tags" basically, so as long
>> as you have another "handle" referencing the same commit a branch points
>> to (be that a tag or another branch), nothing is lost by removing the
>> branch -- you are just removing a tag, not any "real" content.
> 
> Yes, but the "renames" are extremely surprising to a casual contributor.
>
> What if someone has a few commits on, say maint, from before your rename.
> This someone didn't bother to create a topic branch for these commits
> for some reason. What happens when those local commits have been forgotten
> and the new-world-order is pulled? A merge is attempted of the local commits
> and the whole difference between old and new maint. That is likely to
> result in a conflict. So, our imaginary dev restores the local maint and
> puts the local commits on a topic branch and retries only to again see
> a conflict when the pull is attempted. I bet the poor dev will not first
> think that upstream has messed up, but that it is some local crap that is
> happening. How much time will be wasted?
> 
> BTW, just to test this I did the perfectly valid (no local commits on
> maint):
> 
> git checkout maint
> git pull
> 
> And my repo is now in a mess with unresolved conflicts. This rename
> is a mess. It is only clean for you, since it originated from you.
> Everyone else will have to take about the same manual steps you
> did in order to follow. Which is crappy and evil and will only work
> for those of us who pay close attention to the mailing list/docs.
> The poor sods with a git checkout as of last week but having no reason
> to pull for some time will wonder what hit them when they actually do
> pull.
>
OK, I thought about those considerations, but the situation seemed much
less bleak and by no means catastrophic to me; maybe you are right that
that was only due to the fact that the change originated from myself, so
I was fully aware of what it would entail, and didn't try too hard to put
myself in the shoes of casual contributors, who weren't privy to such
details.

Then again (pardon me for being whiny) why didn't you object in time?
Sigh ...

> Also, git history is fuubared.
>
No, having it fubared would mean that at least some once valid SHA-1
have become invalid; this haven't happen.

> E.g. commit 0756a43c3a77
> "Merge branch 'branch-1.13.2' into maint" is in fact no longer on maint.
> How confusing is that?
>
>>> Hopefully there isn't some big chunk of unpublished work that will be
>>> killed by these disruptive changes...
>>>
>> No, there is not.  As said, no pre-existing commit has been dropped by
>> my planned renames.
> 
> 

Regards,
  Stefano

Message #144 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Peter Rosin <peda <at> lysator.liu.se>, 13578 <at> debbugs.gnu.org,
	Automake List <automake <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Wed, 27 Feb 2013 10:25:00 +0900

Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
> You might have good points, and possibly even be completely right...
> But I must ask, why didn't you step up during the lengthy discussion
> about this change, nor objected during the delay (almost a week) that
> was deliberately let pass between the decision and the implementation
> -- precisely to let this kind of late objections to come out?

I just didn't notice the name change... ><

-miles

-- 
Egotist, n. A person of low taste, more interested in himself than in me.

Message #147 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Peter Rosin <peda <at> lysator.liu.se>, 13578 <at> debbugs.gnu.org,
	Automake List <automake <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Wed, 27 Feb 2013 10:31:17 +0900

Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
> And while you *might* have changed my mind before (because you have
> valid points, and maybe it would have better to err on the side of
> safety), I have now already rewritten maint, so rather than messing
> up by rewriting it again (to its old value, granted, but a rewrite
> nonetheless) and reverting an already made decision (and made after
> considerable discussion and not negligible efforts), I'd rather
> stuck with the current minor "mess".

Rewriting "to the old value" makes a _huge_ difference (at least with
git), because people that haven't done a pull or whatever of the "new
value" will then have no problem at all.

So whether another rename causes more or less pain depends on what
proportion of people that have a pointer to your repository do
frequent updates.  As automake seems to be the sort of project that
has mostly "casual" contributors, I'd wager many people _haven't_
pulled the "changed" version, and so would be _helped_ by a
rename-to-the-old-value (and hurt by not doing so).

-miles

-- 
Arrest, v. Formally to detain one accused of unusualness.

Message #150 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Miles Bader <miles <at> gnu.org>
Cc: Peter Rosin <peda <at> lysator.liu.se>, 13578 <at> debbugs.gnu.org,
	Automake List <automake <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Wed, 27 Feb 2013 10:10:51 +0100

On 02/27/2013 02:25 AM, Miles Bader wrote:
> Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
>> You might have good points, and possibly even be completely right...
>> But I must ask, why didn't you step up during the lengthy discussion
>> about this change, nor objected during the delay (almost a week) that
>> was deliberately let pass between the decision and the implementation
>> -- precisely to let this kind of late objections to come out?
> 
> I just didn't notice the name change... ><
> 
In retrospective, since that change wasn't strictly required to implement
the new versioning scheme, it should have been proposed and discussed in
a separate thread, to make sure it sticked out properly ...

Regards,
  Stefano

Message #153 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Miles Bader <miles <at> gnu.org>
Cc: Peter Rosin <peda <at> lysator.liu.se>, 13578 <at> debbugs.gnu.org,
	Automake List <automake <at> gnu.org>
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Wed, 27 Feb 2013 10:12:56 +0100

On 02/27/2013 02:31 AM, Miles Bader wrote:
> Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
>> And while you *might* have changed my mind before (because you have
>> valid points, and maybe it would have better to err on the side of
>> safety), I have now already rewritten maint, so rather than messing
>> up by rewriting it again (to its old value, granted, but a rewrite
>> nonetheless) and reverting an already made decision (and made after
>> considerable discussion and not negligible efforts), I'd rather
>> stuck with the current minor "mess".
> 
> Rewriting "to the old value" makes a _huge_ difference (at least with
> git), because people that haven't done a pull or whatever of the "new
> value" will then have no problem at all.
> 
> So whether another rename causes more or less pain depends on what
> proportion of people that have a pointer to your repository do
> frequent updates.  As automake seems to be the sort of project that
> has mostly "casual" contributors, I'd wager many people _haven't_
> pulled the "changed" version, and so would be _helped_ by a
> rename-to-the-old-value (and hurt by not doing so).
> 
As I said in my reply to Peter, feel free to reach a decision on-list
and implement it.  I'm not going to touch the Automake repository
myself for some (possibly several) days anyway.

Regards,
  Stefano

Message #156 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Wed, 27 Feb 2013 10:28:56 +0100

On 2013-02-26 19:30, Stefano Lattarini wrote:
> Hi Peter.
> 
> On 02/26/2013 12:53 AM, Peter Rosin wrote:
>> On 2013-02-25 10:16, Stefano Lattarini wrote:
>>
>>>
>>> Note that the users can avoid branch-rewriting issues by renaming their
>>> 'master' to 'next' and their 'maint' to 'master' before pulling.  This
>>> should probably be stated in a message (on list *and* on savannah news)
>>> advertising the new versioning and branching scheme (message not yet
>>> written; it will be once the current issue is sorted out).
>>
>> Hiding stuff like that in some documentation or on a mailing list will
>> not help. You should make it *easy* for people to work on and contribute
>> to automake. Forcing everyone to do a bunch of silly boring renames
>> is not *easy*. It's an obstacle, and obstacles make people nervous
>> and uneasy. Not good, and no, you can't document it away.
>>
> You might have good points, and possibly even be completely right...
> But I must ask, why didn't you step up during the lengthy discussion
> about this change, nor objected during the delay (almost a week) that
> was deliberately let pass between the decision and the implementation
> -- precisely to let this kind of late objections to come out?  What is
> the point of having such discussions in the first place, if people who
> oppose a proposed change (maybe even on solid ground and with sound
> reasons) only object *after* the change has been discussed, accepted
> and implemented?

The long winding "eyes glossing over" discussion about version numbers
had nothing in it about branches, except the initial proposal which
stated:

	  * None of 'maint', 'master' and 'next' should be rewindable.

I was not aware that 'master' and 'next' were rewindable before.

Then there was the last message before the implementation that stated:

	In a couple of days, I will proceed with this "branch moving":

	   * branch-1.13.2 -> maint
	   * maint -> master
	   * master -> next


No other message mentions git branches that I could find, but I might
have missed some instance.

Now, there are more than one way to "move branches". The most natural
is to merge your way forward, in fact that's the only one that makes
sense if the branches are *not* *rewindable*.

Thinking about this for a few minutes, I think I would have (with
better commit messages):
  # create 'next'
  $ git branch next master

  # update 'master'
  $ git branch new-master maint
  $ git checkout new-master
  $ git merge --strategy=ours master -m "rename maint -> master"
  $ git checkout master
  $ git merge new-master # a simple fast-forward
  $ git branch -D new-master

  # update 'maint'
  $ git branch new-maint branch-1.13.2
  $ git checkout new-maint
  $ git merge --strategy=ours maint -m "rename branch-1.13.2 -> maint"
  $ git checkout maint
  $ git merge new-maint # a simple fast-forward
  $ git branch -D new-maint

Forgive me for assuming that the branches would not be rewound.

Also, I was away skiing last week, but I wouldn't have caught this
even if I had been "present".

BTW, I assume you could still use the mid part to update master, instead
of waiting for the savannah crew to help you. You just have to replace
the first "git branch new-master ..." with

  $ git branch new-master b4dbcb75

(Because I think b4dbcb75 is what 'maint' was before you rewrote it.)

>>>> It's quite hostile to do non-fast-forwards
>>>> on branches as central as master and maint. And I think git/savannah
>>>> is rejecting them quite rightly!
>>>>
>>> Savannah is rejecting all non-fast-forward pushes (which I find annoying);
>>> but it didn't prevent me from deleting and recreating maint, a change that
>>> will still appear as a non-fast-forward to any clone of our repository.
>>>
>>> The reason it doesn't allow me to delete master as well is that doing so
>>> would prevent a "git clone" from checking out the sources of a freshly
>>> cloned automake, which can be very confusing (and of course, git cannot
>>> be aware of the fact that I intend to re-create 'master' just after
>>> having deleted it).
>>
>> The reason is irrelevant. non-fast-forwards of central branches is evil.
>>
> Mostly, yes.  This time, considering that no commits were actually being
> dropped or rewritten, I believed it wasn't not that bad, and was IMHO
> justified by the new improved versioning and branching scheme.
> 
> And while you *might* have changed my mind before (because you have
> valid points, and maybe it would have better to err on the side of
> safety), I have now already rewritten maint, so rather than messing
> up by rewriting it again (to its old value, granted, but a rewrite
> nonetheless) and reverting an already made decision (and made after
> considerable discussion and not negligible efforts), I'd rather stuck
> with the current minor "mess".
> 
> That said, if it turns out that I'm in minority in supporting such an
> approach, then feel free to revert the maint rewrite [1] (and I'll drop
> the planned master rewrite); I'm not here to forcibly impose my will
> on the majority, at least not when the majority has good points or
> valid concerns.
> 
>   [1] And rename the bug-fixing branch to something like 'fix'
>       or 'micro', and adjust HACKING accordingly -- with a clear
>       and explicative commit message.
> 
> Whatever the result will be, I'm starting to lose faith in the
> usefulness of having lengthy discussion for controversial changes
> beforehand; if we don't and I just go ahead with my idea, some (or
> most) people will complain after the fact; if we do, and a consensus
> is reached and implemented, some people still complain after the
> fact.  Not a great situation, motivational-wise ...

The branch rewinding was not discussed at all, I don't think anyone
even realized it was on the map. Personally, I couldn't care less if
the next major is called 1.14 or 2.0, so I felt I had nothing to add to
the discussion.

>>>> master and maint have never been published as "rewindable", and it should
>>>> be correct to base new work on them. They should be left alone, IMHO.
>>>>
>>> Their content has been left alone in fact; it's their "name" that hasn't.
>>>
>>>> You should have implemented this more gradually, such that next would
>>>> have taken its role directly, but maint and master should have been
>>>> allowed to grow into the correct branches once the relevant releases had
>>>> been made.
>>>>
>>> This would give a very confusing interim period IMHO.
>>
>> Yes, confusing. Changes like this cause confusion.
>>
>>> However, note that that we can still implement such a "gentler transition"
>>> (for 'master' only) if you really want to, by using a new branch name
>>> (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a
>>> temporary "alias" to 'next' until the 2.0 release (at which point all of
>>> 'maint', 'master' and 'next' will be fast-forwarded to the commit that
>>> implements the 2.0 release).  I still prefer to pull this sore tooth out
>>> right now, though.
>>
>> So messy.
>>
> Indeed.  Better be consistent and rewrite 'master' too.
> 
>>>> Or even better, implement the change right after a major
>>>> release so that master and maint would have been correctly positioned
>>>> from the start.
>>>>
>>>> I have a few single-commit local branches that I will simply have to
>>>> cherry-pick to the new world order.
>>>>
>>> No, just rebase them on the new name of the branch they were based on;
>>> that is, if they were based on 'master', they are now to be considered
>>> based on 'next', if they were based on 'maint', they are now to be
>>> considered based on 'master', and if they were based on 'branch-1.13.2'
>>> they are not to be considered based on 'maint'.
>>
>> ( s/are not to/are now to/ )
>>
> Yes, sorry for the typo.
> 
>> Yes, that works. But it is a nuisance.
>>
> Yes, but an easily bearable one IMHO.

Obviously. You have already updated to the new world order, so of course
it's easy for you to bear it. It's relatively easy for anyone that's
aware of the branch rewrite, but you simply can't get the message out
to all parties. Also, at no point have you described how a git newbie
should adjust the local repo, that git fetch is needed because git pull
simply will not work etc.

>>>> Or is there some better way to move
>>>> these branches after their base has been pulled from under them?
>>>>
>>> The good thing is that is has not been really pulled away, just *renamed*.
>>>
>>> Remember that Git branches are just "movable tags" basically, so as long
>>> as you have another "handle" referencing the same commit a branch points
>>> to (be that a tag or another branch), nothing is lost by removing the
>>> branch -- you are just removing a tag, not any "real" content.
>>
>> Yes, but the "renames" are extremely surprising to a casual contributor.
>>
>> What if someone has a few commits on, say maint, from before your rename.
>> This someone didn't bother to create a topic branch for these commits
>> for some reason. What happens when those local commits have been forgotten
>> and the new-world-order is pulled? A merge is attempted of the local commits
>> and the whole difference between old and new maint. That is likely to
>> result in a conflict. So, our imaginary dev restores the local maint and
>> puts the local commits on a topic branch and retries only to again see
>> a conflict when the pull is attempted. I bet the poor dev will not first
>> think that upstream has messed up, but that it is some local crap that is
>> happening. How much time will be wasted?
>>
>> BTW, just to test this I did the perfectly valid (no local commits on
>> maint):
>>
>> git checkout maint
>> git pull
>>
>> And my repo is now in a mess with unresolved conflicts. This rename
>> is a mess. It is only clean for you, since it originated from you.
>> Everyone else will have to take about the same manual steps you
>> did in order to follow. Which is crappy and evil and will only work
>> for those of us who pay close attention to the mailing list/docs.
>> The poor sods with a git checkout as of last week but having no reason
>> to pull for some time will wonder what hit them when they actually do
>> pull.
>>
> OK, I thought about those considerations, but the situation seemed much

Why why why didn't you explain that in your rationale when proposing
the change? If you truly wanted input, you should have stated the
negatives as well in case someone had stronger reasons for being
negative.

> less bleak and by no means catastrophic to me; maybe you are right that
> that was only due to the fact that the change originated from myself, so
> I was fully aware of what it would entail, and didn't try too hard to put
> myself in the shoes of casual contributors, who weren't privy to such
> details.
> 
> Then again (pardon me for being whiny) why didn't you object in time?
> Sigh ...

As stated in my original complaint: "I was not aware that those moves
would be non-fast-forwards, and I think ..."

>> Also, git history is fuubared.
>>
> No, having it fubared would mean that at least some once valid SHA-1
> have become invalid; this haven't happen.

Oh, that's perhaps what it means to have the history fubared according
to your definition, but I stated that it was fuubared (with two 'u's,
mind you), which is something completely different according to my
definition. When this change has been forgotten (and it will be), it
will no longer be possible to say what 'maint' was as of 2013-01-15 by
only looking at the git history. You would have to know that a branch
rewrite took place. Ergo, the history has been fuubared.

>> E.g. commit 0756a43c3a77
>> "Merge branch 'branch-1.13.2' into maint" is in fact no longer on maint.
>> How confusing is that?
>>
>>>> Hopefully there isn't some big chunk of unpublished work that will be
>>>> killed by these disruptive changes...
>>>>
>>> No, there is not.  As said, no pre-existing commit has been dropped by
>>> my planned renames.

Cheers,
Peter

Message #159 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Wed, 27 Feb 2013 10:37:21 +0100

On 2013-02-27 10:28, Peter Rosin wrote:
> The long winding "eyes glossing over" discussion about version numbers
> had nothing in it about branches, except the initial proposal which
> stated:
> 
> 	  * None of 'maint', 'master' and 'next' should be rewindable.
> 
> I was not aware that 'master' and 'next' were rewindable before.

I meant 'maint', not 'next', in the last sentence. Of course.

Cheers,
Peter

Message #162 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Wed, 27 Feb 2013 11:29:43 +0100

On 02/27/2013 10:28 AM, Peter Rosin wrote:
>
> [SNIP]
>
> The long winding "eyes glossing over" discussion about version numbers
> had nothing in it about branches, except the initial proposal which
> stated:
> 
> 	  * None of 'maint', 'master' and 'next' should be rewindable.
>
It also stated:

  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.

I thought that was making clear that the then-current 'maint' and
'master' branches would have needed to be renamed in order to implement
that new scheme.  But re-reading the above, I realize I wasn't making
that clear at all (it sounded clear to me because the details were
fresh and clear in my mind then).

> I was not aware that 'master' and 'next' were rewindable before.
> 
> Then there was the last message before the implementation that stated:
> 
> 	In a couple of days, I will proceed with this "branch moving":
> 
> 	   * branch-1.13.2 -> maint
> 	   * maint -> master
> 	   * master -> next
> 
> 
> No other message mentions git branches that I could find, but I might
> have missed some instance.
> 
> Now, there are more than one way to "move branches". The most natural
> is to merge your way forward,
>
Not in this case, as 'master' had several commits lacking in 'maint'.

> in fact that's the only one that makes
> sense if the branches are *not* *rewindable*.
> 
> Thinking about this for a few minutes, I think I would have (with
> better commit messages):
>   # create 'next'
>   $ git branch next master
> 
>   # update 'master'
>   $ git branch new-master maint
>   $ git checkout new-master
>   $ git merge --strategy=ours master -m "rename maint -> master"
>
This would have obtained the wrong effect; what was in master before my
attempted renaming shouldn't have landed in the new 'master', but only
in 'next'.  In the new 'master', we only wanted what was in the old 'maint'.

>   $ git checkout master
>   $ git merge new-master # a simple fast-forward
>   $ git branch -D new-master
> 
>   # update 'maint'
>   $ git branch new-maint branch-1.13.2
>   $ git checkout new-maint
>   $ git merge --strategy=ours maint -m "rename branch-1.13.2 -> maint"
>   $ git checkout maint
>   $ git merge new-maint # a simple fast-forward
>   $ git branch -D new-maint
>
Same issue as above.

> Forgive me for assuming that the branches would not be rewound.
> 
> Also, I was away skiing last week, but I wouldn't have caught this
> even if I had been "present".
> 
> BTW, I assume you could still use the mid part to update master, instead
> of waiting for the savannah crew to help you.
>
Of course, we don't need any help from Savannah, since, as I said, no
commit has been lost.  If you want to revert the botched renaming, you
just need to rename the current 'maint' to 'branch-1.13.2', and recover
the previous 'maint' from the last merge into 'master' (that has not
been re-written), and delete the 'next' branch.

As I said, if you reach a consensus on that (and I guess you will),
feel free to go ahead with that.  No objection from me.

> You just have to replace
> the first "git branch new-master ..." with
> 
>   $ git branch new-master b4dbcb75
> 
> (Because I think b4dbcb75 is what 'maint' was before you rewrote it.)

>>
>> [BIG SNIP]
>>
>> OK, I thought about those considerations, but the situation seemed much
>> less bleak [SNIP]
> 
> Why why why didn't you explain that in your rationale when proposing
> the change? If you truly wanted input, you should have stated the
> negatives as well in case someone had stronger reasons for being
> negative.
>
Because I mistakenly didn't think they were relevant negatives.  So
new rule for me: from now on, all the negative sides I can think of
are relevant, no matter how tiny or even "irrelevant" they appear
to me.

> [SNIP]

Regards,
  Stefano

Message #165 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Thu, 28 Feb 2013 00:00:04 +0100

On 2013-02-27 11:29, Stefano Lattarini wrote:
> On 02/27/2013 10:28 AM, Peter Rosin wrote:
>>
>> [SNIP]
>>
>> The long winding "eyes glossing over" discussion about version numbers
>> had nothing in it about branches, except the initial proposal which
>> stated:
>>
>> 	  * None of 'maint', 'master' and 'next' should be rewindable.
>>
> It also stated:
> 
>   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.
> 
> I thought that was making clear that the then-current 'maint' and
> 'master' branches would have needed to be renamed in order to implement
> that new scheme.  But re-reading the above, I realize I wasn't making
> that clear at all (it sounded clear to me because the details were
> fresh and clear in my mind then).

It also didn't state *when* the roles would change. The natural point
is after a major release when master and maint have converged
anyway.

>> I was not aware that 'master' and 'next' were rewindable before.
>>
>> Then there was the last message before the implementation that stated:
>>
>> 	In a couple of days, I will proceed with this "branch moving":
>>
>> 	   * branch-1.13.2 -> maint
>> 	   * maint -> master
>> 	   * master -> next
>>
>>
>> No other message mentions git branches that I could find, but I might
>> have missed some instance.
>>
>> Now, there are more than one way to "move branches". The most natural
>> is to merge your way forward,
>>
> Not in this case, as 'master' had several commits lacking in 'maint'.

See below.

>> in fact that's the only one that makes
>> sense if the branches are *not* *rewindable*.
>>
>> Thinking about this for a few minutes, I think I would have (with
>> better commit messages):
>>   # create 'next'
>>   $ git branch next master
>>
>>   # update 'master'
>>   $ git branch new-master maint
>>   $ git checkout new-master
>>   $ git merge --strategy=ours master -m "rename maint -> master"
>>
> This would have obtained the wrong effect; what was in master before my
> attempted renaming shouldn't have landed in the new 'master', but only
> in 'next'.  In the new 'master', we only wanted what was in the old 'maint'.

The functional changes would not have appeared on the new branch (due to
the 'ours' strategy), but yes, the commits would appear to be present on
the new branch even if their corresponding changes would not, and I guess
the generated ChangeLog would have been wrong too (listing changes that
simply aren't there).

The nice thing with assigning new roles using merges is that the history
is transparent. It will show exactly what has happened for anyone that can
be bothered to look.

But as I said, I only thought about it for a few minutes...

>>   $ git checkout master
>>   $ git merge new-master # a simple fast-forward
>>   $ git branch -D new-master
>>
>>   # update 'maint'
>>   $ git branch new-maint branch-1.13.2
>>   $ git checkout new-maint
>>   $ git merge --strategy=ours maint -m "rename branch-1.13.2 -> maint"
>>   $ git checkout maint
>>   $ git merge new-maint # a simple fast-forward
>>   $ git branch -D new-maint
>>
> Same issue as above.

Add these "abnormal" merges, and I think all would have been fine
(apart from the generated ChangeLog mentioned above):

$ git checkout master
$ git merge --strategy=ours maint
$ git checkout next
$ git merge --strategy=ours master

But, I don't actually think this branch restructuring was a good
idea at all at this point in time. Branch reorganizations are
better done in conjunction with a new major release.

(BTW, if it was up to me, I would require a really good reason
to ever release a 1.14, given that 1.14 looks like an old style
major release, and has been mentioned multiple times on list,
in commit messages and in code and tests. It's simply best if
1.14 never gets released).

>> Forgive me for assuming that the branches would not be rewound.
>>
>> Also, I was away skiing last week, but I wouldn't have caught this
>> even if I had been "present".
>>
>> BTW, I assume you could still use the mid part to update master, instead
>> of waiting for the savannah crew to help you.
>>
> Of course, we don't need any help from Savannah, since, as I said, no
> commit has been lost.  If you want to revert the botched renaming, you
> just need to rename the current 'maint' to 'branch-1.13.2', and recover
> the previous 'maint' from the last merge into 'master' (that has not
> been re-written), and delete the 'next' branch.

What I meant was that you can use (some of) my above proposed merges
to go forward with the new role for master instead of requiring help
from Savannah to allow rewriting master.

> As I said, if you reach a consensus on that (and I guess you will),
> feel free to go ahead with that.  No objection from me.

You are the maintainer, I'm just stating my opinion. I honestly don't
know what I think is best to do now, when the rewriting has already
started but not yet completed. I guess it's your mess, and I don't
really want to take responsibility for it by stepping in and trying
to clear it up. I.e., I will only offer my opinion at this point.

>> You just have to replace
>> the first "git branch new-master ..." with
>>
>>   $ git branch new-master b4dbcb75
>>
>> (Because I think b4dbcb75 is what 'maint' was before you rewrote it.)
> 
>>>
>>> [BIG SNIP]
>>>
>>> OK, I thought about those considerations, but the situation seemed much
>>> less bleak [SNIP]
>>
>> Why why why didn't you explain that in your rationale when proposing
>> the change? If you truly wanted input, you should have stated the
>> negatives as well in case someone had stronger reasons for being
>> negative.
>>
> Because I mistakenly didn't think they were relevant negatives.  So

I simply don't get that, branch rewriting is just not something you
inflict on your downstream (unless there truly is no other option, or
if you have declared that you would up front).

> new rule for me: from now on, all the negative sides I can think of
> are relevant, no matter how tiny or even "irrelevant" they appear
> to me.

Cheers,
Peter

Message #168 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nate Bargmann <n0nb <at> n0nb.us>
Cc: 13578 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Thu, 28 Feb 2013 00:38:37 +0100

On 02/27/2013 02:07 PM, Nate Bargmann wrote:
>
> [SNIP]
>
>> Not in this case, as 'master' had several commits lacking in 'maint'.
> 
> Would 'git cherry-pick' have worked? 
>
No, because those commit were to be *dropped* (not added) from master;
the old 'master' containing them was to be renamed to 'next'.

> [SNIP]
> 
> In other words, master contained commits intended for '2.0'+ (for
> instance) that you didn't want in 1.13+, etc.? 
>
Exactly.

> Perhaps a new branch for
> 1.13+ cut from some earlier commit in master and leaving master alone
> would have worked?
>
What would have worked with minimal disruption would have been to keep
the current names until the next major version (maybe just renaming
'branch-1.13.2' to 'fix' or 'micro' *after* the bug-fixing release);
just after the new major release, 'fix', 'maint' and 'master' would
have pointed to the *same* commit, so we could have juggled and
swapped their names without causing any non-ff push.

I thought the disruption of doing the renames right now would have
been negligible anyway, but apparently I was badly wrong in that.

> master would have then been consigned to being for
> new development which isn't what you explicitly stated in the policy
> above.  I have to agree with Miles on the common assumption of the
> master branch in Git as sort of a quasi-stable of the development tree.
>
So we should maybe go (after the next major release) with this naming
scheme for the branches?

  * maint -> for next micro version
  * stable -> for next minor version
  * master -> for next major version

> [SNIP]

Thank,
  Stefano

Message #171 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Thu, 28 Feb 2013 00:39:36 +0100

On 02/28/2013 12:00 AM, Peter Rosin wrote:
>
> [SNIP]
>
> What I meant was that you can use (some of) my above proposed merges
> to go forward with the new role for master instead of requiring help
> from Savannah to allow rewriting master.
>
So... now are you ok with *completing* my branch renaming instead
of reverting the part of it that has already been done?  Puzzled...

>> As I said, if you reach a consensus on that (and I guess you will),
>> feel free to go ahead with that.  No objection from me.
> 
> You are the maintainer, I'm just stating my opinion. I honestly don't
> know what I think is best to do now, when the rewriting has already
> started but not yet completed. I guess it's your mess, and I don't
> really want to take responsibility for it by stepping in and trying
> to clear it up. I.e., I will only offer my opinion at this point.
>
Fine, I'll revert the partial branch renaming when I have time to do
that with enough care and attention to avoid another half-done botch-up
(might be few days or a week or more; please don't push to the repo in
the meantime).

> [BIG SNIP]

Regards,
  Stefano

Message #174 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Thu, 28 Feb 2013 08:59:43 +0100

On 2013-02-28 00:39, Stefano Lattarini wrote:
> On 02/28/2013 12:00 AM, Peter Rosin wrote:
>>
>> [SNIP]
>>
>> What I meant was that you can use (some of) my above proposed merges
>> to go forward with the new role for master instead of requiring help
>> from Savannah to allow rewriting master.
>>
> So... now are you ok with *completing* my branch renaming instead
> of reverting the part of it that has already been done?  Puzzled...

Personally, I will adapt to whatever you do. My objection was never
about me personally, since I was aware of what took place and got
clued in by your message about the troubles rewriting master. I am
mostly just baffled that you even consider branch rewriting to be
an option at all. If it weren't for the Savannah issues, I would
probably have missed it, because I don't read automake-commit very
carefully. Barring that "Savannah issues" mail, I would probably have
first noticed the change when I pulled the next time (who knows when
that would have happened, I don't pull the automake repo just for
thrills). And I would have been extremely surprised by the failed
merge during that pull.

Who knows how many there are out there with a clone of the repo, but
not following the mailing lists very carefully? Those are the ones
I'm thinking about, and I think you should too. But since I'm not the
maintainer, I will not have to face them when they have wasted time
trying to figure out what has happened when their next pull fails.
In other words, what to do next is your call.

>>> As I said, if you reach a consensus on that (and I guess you will),
>>> feel free to go ahead with that.  No objection from me.
>>
>> You are the maintainer, I'm just stating my opinion. I honestly don't
>> know what I think is best to do now, when the rewriting has already
>> started but not yet completed. I guess it's your mess, and I don't
>> really want to take responsibility for it by stepping in and trying
>> to clear it up. I.e., I will only offer my opinion at this point.
>>
> Fine, I'll revert the partial branch renaming when I have time to do
> that with enough care and attention to avoid another half-done botch-up
> (might be few days or a week or more; please don't push to the repo in
> the meantime).

A second rewrite "undoing" (quotes here since the rewrite can't be
undone, and me and probably others as well will have to adjust the
local repo a second time) the first is probably the lesser evil,
even if it is another branch rewrite.

Cheers,
Peter

Message #177 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: automake <at> gnu.org, Nate Bargmann <n0nb <at> n0nb.us>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Thu, 28 Feb 2013 17:12:43 +0900

Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
> So we should maybe go (after the next major release) with this naming
> scheme for the branches?
>
>   * maint -> for next micro version
>   * stable -> for next minor version
>   * master -> for next major version

That seems to match common practice, insofar as I understand it...

[Another consideration is whether you have a single named branch for
maintenance (e.g. "maint", and "stable"), or just use version-named
branches (and thus can maintain multiple versions simultaneously).]

-miles

-- 
Future, n. That period of time in which our affairs prosper, our friends
are true and our happiness is assured.

Message #180 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Russ Allbery <rra <at> stanford.edu>
To: automake <at> gnu.org,  13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Thu, 28 Feb 2013 05:34:14 -0800

I want to preface this by noting that I think this is really much ado
about nothing.  I've done these sorts of non-rewindable branch renamings
before, and while they're mildly annoying, it's pretty rare that there are
tons of people out there with Git clones that aren't following the
development mailing list and get somehow confused.  It's just not that big
of a deal; basically everyone who has bothered to clone your Git
repository for the typical smallish project (and Automake, despite being
very widely used, is from a development perspective a smallish project) is
following the mailing list anyway and will see the instructions.

Also, those of us who have been using Git for a while will have run into
this before and will have some idea of how to deal with it.  And, failing
that, even if one can't figure out the right way to manipulate one's local
repository to prepare, there's always the hammer approach of git
format-patch to generate whatever local changes one has, cloning a new
repository, and git am to put them back, which really isn't that big of a
deal.

Therefore, I think whoever is active in development should basically just
do whatever they want to do and the rest of us will cope.  I think it's
way more important that the primary developers be comfortable with the
setup (and not feel demotivated by having to argue about it) than any
particular scheme of Git purity be adopted.

That said, if and only if the folks who are mostly doing the work are
interested in the more theoretical discussion of possible schemes....

Miles Bader <miles <at> gnu.org> writes:
> Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:

>> So we should maybe go (after the next major release) with this naming
>> scheme for the branches?
>>
>>   * maint -> for next micro version
>>   * stable -> for next minor version
>>   * master -> for next major version

> That seems to match common practice, insofar as I understand it...

> [Another consideration is whether you have a single named branch for
> maintenance (e.g. "maint", and "stable"), or just use version-named
> branches (and thus can maintain multiple versions simultaneously).]

I'd say that the latter (using separate branches for each version) is the
most common.  One other advantage is that if you don't have any changes
that need to be restricted to a particular scope, you don't bother
creating the branch.

So, you start with just:

    master -> for next major version

plus of course tags for each release.

At the point at which you have a change that should go into the next minor
version and a change that should *not* go into the next minor version (in
other words, at the point at which the maintenance diverges), you create a
new branch:

    stable-2 (for maintenance of version 2.* for example)

make the change on that branch and merge that branch to master.  (Or make
the change on master and cherry-pick it to the branch, but it's always
nice to merge the stable branch onto master to be sure you didn't miss
anything.)

Since it's quite likely that you'll want this level of branching, it's of
course reasonable to make this branch proactively.

You make minor and micro releases for version 2.* from that branch up
until the point at which there's something that needs to go into the micro
release and other changes that shouldn't, at which point you might create:

    stable-2.1 (for example)

to manage further 2.1.* micro releases.

Many projects never need that last level of branching.  I suspect you'll
find that you will use it once or twice but not as a systematic practice.
Usually, it's easier to just make releases from the stable branch and
version them (either minor or micro) according to the nature of the
changes that have accumulated.

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

Message #183 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Automake List <automake <at> gnu.org>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Tue, 05 Mar 2013 15:34:52 +0100

On 02/28/2013 08:59 AM, Peter Rosin wrote:
>
> [SNIP]
> 
> A second rewrite "undoing" (quotes here since the rewrite can't be
> undone, and me and probably others as well will have to adjust the
> local repo a second time) the first is probably the lesser evil,
> even if it is another branch rewrite.
> 
It should be done now.  Please check the repository really is in a correct
state.

Regards,
  Stefano

Message #186 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Miles Bader <miles <at> gnu.org>
Cc: automake <at> gnu.org, Nate Bargmann <n0nb <at> n0nb.us>, 13578 <at> debbugs.gnu.org
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Tue, 05 Mar 2013 15:35:31 +0100

On 02/28/2013 09:12 AM, Miles Bader wrote:
> Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
>> So we should maybe go (after the next major release) with this naming
>> scheme for the branches?
>>
>>   * maint -> for next micro version
>>   * stable -> for next minor version
>>   * master -> for next major version
> 
> That seems to match common practice, insofar as I understand it...
>
OK, I don't dislike this naming scheme, so I will implement it once 1.14
has been released (at that point, we'll be able to do so without having
to resort to non-fast-forward pushes).  That might take an undetermined
time between a couple of months and forever.

I have no intention of discussing further the bike-shedding of branch
naming, so this naming scheme will be the one we'll use, period.

> [Another consideration is whether you have a single named branch for
> maintenance (e.g. "maint", and "stable"), or just use version-named
> branches (and thus can maintain multiple versions simultaneously).]
>
The former, I only want to have one maintenance branch.  Having several
for older versions is just too work for no real gain (and if a security
fix is needed, bug-fixing branches for several old releases can just be
created on demand without anu fuss).

Thanks for the feedback, and best regards,
  Stefano

Message #199 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: bug#13578 <13578 <at> debbugs.gnu.org>
Subject: Re: Status: A new versioning scheme for automake releases,
 and a new branching scheme for the Git repository
Date: Sat, 17 Jun 2017 03:16:38 +0200

Hello,

As the new maintainer, I would like to change the branch naming
convention to make the life of casual contributors easier.  The issue is
that when someone clone the Automake repository, it defaults to the
"master" branch which is a "not ready to be released" development branch
and not a particularly active one (I mean less active than the other
;)).

Right now we are using this branch naming scheme:

   - micro: for next micro version
   - minor: for next minor version
   - master: for next major version

Given the current state of Automake I consider that the main scenario
for contributing to Automake is either fixing a bug or developping an
additional feature ontop of the current release version (1.15).  As a
consequence the current branching scheme requires newcomers to read
through the HACKING file to understand that they have to base their work
either on the "micro" or "minor" branch.

One solution would be to change the default branch used when cloning the
repository, but that would look weird on its own to have a default not
named "master" given the fact that it is a well accepted default.  As a
consequence I am not considering it.

What I am proposing is the following branch name scheme:

   - master: for the next version to be released (currently a minor version)
   - maint: for the previous releases (major or minor) merged
            from master and their bug fixing commits leading to a micro
            version release.
   - next: for the "not ready to be release" Automake 2.0 that should
           be merged in master when ready (if ever)

My reasoning is that developping a feature branche should be based on
the code that will appear in the next release by default, and in the
case of bugs if someone find one on the previous release it is highly
probable that it is still reproducible in the next coming release unless
it has already been fixed.

Unless there are better suggestions or valid objections proposed in the
following week, I will send a request to the Savannah administrators to
apply the following renaming:

   - master -> next
   - minor -> master
   - micro -> maint

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Message #202 received at 13578 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: bug#13578 <13578 <at> debbugs.gnu.org>
Cc: Automake-patches <automake-patches <at> gnu.org>, Automake <automake <at> gnu.org>
Subject: Re: bug#13578: Status: A new versioning scheme for automake releases,
 and a new branching scheme for the Git repository
Date: Wed, 20 Sep 2017 01:09:37 +0200

Hello,

Mathieu Lirzin <mthl <at> gnu.org> writes:

> Right now we are using this branch naming scheme:
>
>    - micro: for next micro version
>    - minor: for next minor version
>    - master: for next major version
>
> Given the current state of Automake I consider that the main scenario
> for contributing to Automake is either fixing a bug or developping an
> additional feature ontop of the current release version (1.15).  As a
> consequence the current branching scheme requires newcomers to read
> through the HACKING file to understand that they have to base their work
> either on the "micro" or "minor" branch.
>
[...]
> What I am proposing is the following branch name scheme:
>
>    - master: for the next version to be released (currently a minor version)
>    - maint: for the previous releases (major or minor) merged
>             from master and their bug fixing commits leading to a micro
>             version release.
>    - next: for the "not ready to be release" Automake 2.0 that should
>            be merged in master when ready (if ever)
>
> Unless there are better suggestions or valid objections proposed in the
> following week, I will send a request to the Savannah administrators to
> apply the following renaming:
>
>    - master -> next
>    - minor -> master
>    - micro -> maint

After doing that request to the Savannah administrators which has not
been answered after more than 2 months [1]. I have decided to proceed
with the the branch renaming myself by resetting the 'master' branch and
then merging 'minor' into 'master' manually.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[1] https://lists.gnu.org/archive/html/savannah-hackers/2017-07/msg00002.html

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.