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

[Stefano Lattarini]

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

[Jack Kelly]

Post by Stefano Lattarini
* 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

[Thien-Thi Nguyen]

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

[Stefano Lattarini]

Post by Thien-Thi Nguyen
() Mon, 28 Jan 2013 20:48:59 +0100
[...]
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).

Post by Thien-Thi Nguyen
and methodically use them in the ChangeLog entries.

This would be overkill IMVHO.

Post by Thien-Thi Nguyen
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
[...]
These details should also be explained in HACKING.

Again, +1

Post by Thien-Thi Nguyen
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

[Peter Johansson]

Hi Stefano,

Post by Stefano Lattarini
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).
- 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.
- 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.
* 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
http://lists.gnu.org/archive/html/bug-automake/2012-07/msg00107.html
* 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?

Post by Stefano Lattarini
* 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.

Post by Stefano Lattarini
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

[Dave Goodell]

Post by Stefano Lattarini
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

[Stefano Lattarini]

Post by Peter Johansson
Hi Stefano,

Hi Peter and everybody, and thanks for the feedback.

Post by Peter Johansson
[SNIP]

Post by Stefano Lattarini
* 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.

Post by Peter Johansson

Post by Stefano Lattarini
* 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.

Post by Peter Johansson
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.

Post by Peter Johansson

Post by Stefano Lattarini
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.

Post by Peter Johansson
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).

Post by Peter Johansson
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.

Post by Peter Johansson
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.

Post by Peter Johansson
If you expect more major releases than minor releases,

I don't (albeit this concern of yours is something to be kept in mind).

Post by Peter Johansson
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
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 :-)

Post by Peter Johansson
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

[Daniel Herring]

Post by Stefano Lattarini
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

[Stefano Lattarini]

Post by Daniel Herring

Post by Stefano Lattarini
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.

Post by Daniel Herring
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 :-)

Post by Daniel Herring
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.

Post by Daniel Herring
(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.

Post by Daniel Herring
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).

Post by Daniel Herring
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.

Post by Daniel Herring
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.

Post by Daniel Herring
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?

Post by Daniel Herring
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.

Post by Daniel Herring
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.

Post by Daniel Herring
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).

Post by Daniel Herring
Hope that helps,
Daniel

Thanks,
Stefano

[Eric Dorland]

Post by Stefano Lattarini
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).
- 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.
- 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.
* 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
http://lists.gnu.org/archive/html/bug-automake/2012-07/msg00107.html
* 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

Post by Stefano Lattarini
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
* 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.

Post by Stefano Lattarini
And of course, we'll have to publicize the new versioning scheme
ASAP, and with quite high visibility. I propose the following
- A news item in the savannah AUtomake page;
- A message to autotools-announce;
- An entry in the NEWS file of 1.13.2.
- ??? (suggestions welcome)
-*-*-
Feedback, opinions, objections?
Regards,
Stefano

[Stefano Lattarini]

[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
[SNIP PROPOSAL for new branching scheme]

Post by Stefano Lattarini
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

[Stefano Lattarini]

Hi Diego.

Post by Stefano Lattarini
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
- 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

[Diego Elio Pettenò]

Post by Stefano Lattarini
<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.

Post by Stefano Lattarini
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...

Post by Stefano Lattarini
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).

Post by Stefano Lattarini
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...

Post by Stefano Lattarini
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.

[Jack Kelly]

Post by Diego Elio Pettenò
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

[Diego Elio Pettenò]

Post by Jack Kelly
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.

Post by Jack Kelly
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..

[Jack Kelly]

Post by Diego Elio Pettenò

Post by Jack Kelly
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?

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

Post by Jack Kelly
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

[Stefano Lattarini]

Hi Diego, Jack, sorry for the late reply.

Post by Jack Kelly

Post by Diego Elio Pettenò

Post by Jack Kelly
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?

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

Post by Jack Kelly
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

[Diego Elio Pettenò]

Post by Stefano Lattarini
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.

[Stefano Lattarini]

Post by Diego Elio Pettenò

Post by Stefano Lattarini
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?

Post by Diego Elio Pettenò
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.

Post by Diego Elio Pettenò
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).

Post by Diego Elio Pettenò
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.

Post by Diego Elio Pettenò
and leads to decency, I'd say.

Thanks,
Stefano

[Diego Elio Pettenò]

Post by Stefano Lattarini

Post by Diego Elio Pettenò
Given that 1.12.0 was "not really final release",

Why not?

AM_PROG_MKDIR_P.

Post by Stefano Lattarini
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..

Post by Stefano Lattarini
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.

Post by Stefano Lattarini
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.

[Daniel Herring]

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

[Stefano Lattarini]

Post by Diego Elio Pettenò

Post by Stefano Lattarini

Post by Diego Elio Pettenò
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).

Post by Diego Elio Pettenò

Post by Stefano Lattarini
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.

Post by Diego Elio Pettenò

Post by Stefano Lattarini
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).

Post by Diego Elio Pettenò

Post by Stefano Lattarini
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.

Post by Diego Elio Pettenò
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

[Diego Elio Pettenò]

Post by Stefano Lattarini
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

[Stefano Lattarini]

Hi Diego.

Post by Diego Elio Pettenò

Post by Stefano Lattarini
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).
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.
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

[Miles Bader]

Post by Stefano Lattarini
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

[Stefano Lattarini]

Hi Miles.

Post by Miles Bader

Post by Stefano Lattarini
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).

Post by Miles Bader
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.

Post by Miles Bader
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

[Miles Bader]

Post by Stefano Lattarini

Post by Miles Bader

Post by Stefano Lattarini
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.

[Stefano Lattarini]

Post by Miles Bader

Post by Stefano Lattarini

Post by Miles Bader

Post by Stefano Lattarini
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.

Post by Miles Bader
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

[Miles Bader]

Post by Stefano Lattarini
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

[Vincent Torri]

On Tue, Feb 12, 2013 at 9:38 AM, Stefano Lattarini

Post by Stefano Lattarini

Post by Miles Bader

Post by Stefano Lattarini

Post by Miles Bader

Post by Stefano Lattarini
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

[Nate Bargmann]

Post by Vincent Torri
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

I was advised by a Debian maintainer to use tilde '~' as the separator
as any text following it will be considered "older". For example, in
our project 'Hamlib-3.0~git' is "older" than 'Hamlib-3.0' will be once
released. A hyphen or underscore trips this logic up, as I understand
it, for both .deb and .rpm formats. While this is good practice from a
package mainter's POV, it has not been a problem as we ask that such
code not be packaged by distributions. The extra text is a human
convenience add-on.

Also, the practice of using the "prior" released version number as the
base for the next version's beta is a bit confusing to me. The Linux
kernel model of the *next* planned release tagged with an additional
"rc1", "beta", "git", what-have-you always seemed more logical to me, at
least. Our project adopted this approach of versioning of base +1
(always arbitrary) for the next planned released so that beta testers
and developers are well aware of the next planned version and that
additional characters following a '~' means a yet to be released version.

In other words, 1.14~git, 1.14~beta, 1.14~rc1, make more sense to me for
the forthcoming 1.14 release than using 1.13+whatever which magically
is promoted to 1.14 upon release. JMHO.

- Nate

[Miles Bader]

Post by Nate Bargmann
I was advised by a Debian maintainer to use tilde '~' as the
separator as any text following it will be considered "older". For
example, in our project 'Hamlib-3.0~git' is "older" than
'Hamlib-3.0' will be once released. A hyphen or underscore trips
this logic up, as I understand it, for both .deb and .rpm formats.

This is a Debian-specific syntax, for use in Debian package version
numbers. It's a handy way for the Debian maintainer to directly
represent various existing package version naming schemes with only
mechanical changes (typical, replacing a "_" or "-" with "~"), but I
don't think there's any intent that upstreams should adopt this syntax
directly (though I suppose it doesn't particularly hurt if they
do...).

-miles

[Diego Elio Pettenò]

Post by Stefano Lattarini
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).

[Stefano Lattarini]

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

Post by Stefano Lattarini
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).
- 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.
- 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.
* 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
http://lists.gnu.org/archive/html/bug-automake/2012-07/msg00107.html
* 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
* 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
- 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

[Stefano Lattarini]

Post by Stefano Lattarini
<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< ----

Post by Stefano Lattarini
From 97aaf121e92767dc06385d020dd30cdfaa86126f Mon Sep 17 00:00:00 2001

Message-Id: <***@gmail.com>
From: Stefano Lattarini <***@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 <***@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"

[Stefano Lattarini]

Post by Stefano Lattarini

Post by Stefano Lattarini
<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

[Stefano Lattarini]

Post by Stefano Lattarini

Post by Stefano Lattarini
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< ----

Post by Stefano Lattarini
From d5f83b89cc4d2da9078669018877b3bac5c2fadc Mon Sep 17 00:00:00 2001

Message-Id: <***@gmail.com>
From: Stefano Lattarini <***@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 <***@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.

[Stefano Lattarini]

Post by Stefano Lattarini

Post by Stefano Lattarini

Post by Stefano Lattarini
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.

* 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

[Stefano Lattarini]

Post by Stefano Lattarini

Post by Stefano Lattarini

Post by Stefano Lattarini
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.

* 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

[Thien-Thi Nguyen]

() Stefano Lattarini <***@gmail.com>
() Sat, 23 Feb 2013 19:06:14 +0100

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

I believe the project maintainer must write to the sysadmins requesting
a specific change. GNU RCS is in a similar state (IIUC), the resolution
of which is (perhaps) the exchange of ‘master’ and a non-‘master’ names
(HEAD pointers). I say "perhaps" because i'm not really sure. More
perplexed mumblings at: <http://www.gnuvola.org/u/2013/01/24h09.html>.

The point is: For timely resolution, you need to take direct action.

Let RCS's (ever-growing) lacuna serve as a warning!

[Peter Rosin]

Post by Stefano Lattarini

Post by Stefano Lattarini
* 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

[Stefano Lattarini]

Post by Peter Rosin

Post by Stefano Lattarini

Post by Stefano Lattarini
* 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).

Post by Peter Rosin
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).

Post by Peter Rosin
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.

Post by Peter Rosin
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.

Post by Peter Rosin
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'.

Post by Peter Rosin
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.

Post by Peter Rosin
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

[Peter Rosin]

Post by Stefano Lattarini

Post by Peter Rosin

Post by Stefano Lattarini

Post by Stefano Lattarini
* 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.

Post by Stefano Lattarini

Post by Peter Rosin
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.

Post by Stefano Lattarini

Post by Peter Rosin
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.

Post by Peter Rosin
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.

Post by Stefano Lattarini
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.

Post by Stefano Lattarini

Post by Peter Rosin
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.

Post by Stefano Lattarini

Post by Peter Rosin
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?

Post by Stefano Lattarini

Post by Peter Rosin
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.

[Stefano Lattarini]

Hi Peter.

Post by Peter Rosin

Post by Stefano Lattarini
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?

Post by Peter Rosin

Post by Stefano Lattarini

Post by Peter Rosin
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 ...

Post by Peter Rosin

Post by Stefano Lattarini

Post by Peter Rosin
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.

Post by Peter Rosin
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.

Post by Stefano Lattarini
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.

Post by Peter Rosin

Post by Stefano Lattarini

Post by Peter Rosin
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.

Post by Peter Rosin
Yes, that works. But it is a nuisance.

Yes, but an easily bearable one IMHO.

Post by Peter Rosin

Post by Stefano Lattarini

Post by Peter Rosin
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
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 ...

Post by Peter Rosin
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.

Post by Peter Rosin
E.g. commit 0756a43c3a77
"Merge branch 'branch-1.13.2' into maint" is in fact no longer on maint.
How confusing is that?

Post by Stefano Lattarini

Post by Peter Rosin
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

[Miles Bader]

Post by Stefano Lattarini
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

[Stefano Lattarini]

Post by Miles Bader

Post by Stefano Lattarini
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

[Miles Bader]

Post by Stefano Lattarini
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

[Stefano Lattarini]

Post by Miles Bader

Post by Stefano Lattarini
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

[Peter Rosin]

Post by Stefano Lattarini
Hi Peter.

Post by Peter Rosin

Post by Stefano Lattarini
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.)

Post by Stefano Lattarini

Post by Peter Rosin

Post by Stefano Lattarini

Post by Peter Rosin
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.

Post by Stefano Lattarini

Post by Peter Rosin

Post by Stefano Lattarini

Post by Peter Rosin
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.

Post by Peter Rosin
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.

Post by Stefano Lattarini
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.

Post by Peter Rosin

Post by Stefano Lattarini

Post by Peter Rosin
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.

Post by Peter Rosin
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.

Post by Stefano Lattarini

Post by Peter Rosin

Post by Stefano Lattarini

Post by Peter Rosin
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
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.

Post by Stefano Lattarini
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 ..."

Post by Stefano Lattarini

Post by Peter Rosin
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.

Post by Stefano Lattarini

Post by Peter Rosin
E.g. commit 0756a43c3a77
"Merge branch 'branch-1.13.2' into maint" is in fact no longer on maint.
How confusing is that?

Post by Stefano Lattarini

Post by Peter Rosin
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

[Peter Rosin]

Post by Peter Rosin
The long winding "eyes glossing over" discussion about version numbers
had nothing in it about branches, except the initial proposal which
* 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

[Stefano Lattarini]

Post by Peter Johansson
[SNIP]
The long winding "eyes glossing over" discussion about version numbers
had nothing in it about branches, except the initial proposal which
* 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).

Post by Peter Johansson
I was not aware that 'master' and 'next' were rewindable before.
* 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'.

Post by Peter Johansson
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
# 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'.

Post by Peter Johansson
$ 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.

Post by Peter Johansson
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.

Post by Peter Johansson
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.

Post by Peter Johansson
[SNIP]

Regards,
Stefano

[Nate Bargmann]

Post by Stefano Lattarini
I also propose the following change to the branching scheme currently
* 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).

As I just lurk looking for tips as I'm a downstream prjoct
maintainer/developer, I did not pay much attention other than to know
that version numbers would be changing in the future. Fine.

As to the three bullet points above, those are sensible policies, IMO.
I'll admit that I don't see the need for any renaming of branches, which
I presumed was bad in Git land, but not being an experienced Git
maintainer (only two years under my belt) I kept quiet, particularly
since this isn't my project. :-)

Post by Stefano Lattarini
Not in this case, as 'master' had several commits lacking in 'maint'.

Would 'git cherry-pick' have worked? I've used it a lot between branches
that have divereged to where I would not want a normal merge but for the
patch in question cherry picking allowed me to update the other branch
where the individual files had not diverged, if that makes sense. To
track the history of the cherry-pick I used the '-x' option to give a
link back to the commit it was 'picked from.

Post by Stefano Lattarini
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'.

In other words, master contained commits intended for '2.0'+ (for
instance) that you didn't want in 1.13+, etc.? Perhaps a new branch for
1.13+ cut from some earlier commit in master and leaving master alone
would have worked? 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.

In the project I've inherited, I look at master as the development trunk
and stable releases are branched off of it. In a stable branch any
"point" releases are simply signed annotated tags and not a new branch.
For my purposes a stable branch indcates new or improved hardware
support and "point" release tags indicate bug fixes and nothing more.
In fact I have one long running stable branch that is a year old that
has received various fixes while master continues to track toward our
next major release. Almost no cherry-picking is taking place between
them now.

Developers are free to create topic branches and merge them into master
as they see fit. In fact I have one such branch where I added, at long
last, Readline support to our testing utilities. I'll probably merge it
into master and delete it this weekend.

The good thing about Git is that it does not eforce such policy. The
bad thing about Git is that it does not enforce such policy. ;-)

- Nate

[Stefano Lattarini]

Post by Peter Johansson
[SNIP]

Post by Stefano Lattarini
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'.

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

Exactly.

Post by Peter Johansson
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.

Post by Peter Johansson
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

Post by Peter Johansson
[SNIP]

Thank,
Stefano

[Miles Bader]

Post by Stefano Lattarini
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

[Russ Allbery]

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

Post by Miles Bader

Post by Stefano Lattarini
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.

[Stefano Lattarini]

Post by Miles Bader

Post by Stefano Lattarini
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.

Post by Miles Bader
[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

[Peter Rosin]

Post by Stefano Lattarini

Post by Peter Johansson
[SNIP]
The long winding "eyes glossing over" discussion about version numbers
had nothing in it about branches, except the initial proposal which
* None of 'maint', 'master' and 'next' should be rewindable.

I also propose the following change to the branching scheme currently
* 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.

Post by Stefano Lattarini

Post by Peter Johansson
I was not aware that 'master' and 'next' were rewindable before.
* 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.

Post by Stefano Lattarini

Post by Peter Johansson
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
# 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...

Post by Stefano Lattarini

Post by Peter Johansson
$ 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).

Post by Stefano Lattarini

Post by Peter Johansson
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.

Post by Stefano Lattarini
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.

Post by Stefano Lattarini

Post by Peter Johansson
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).

Post by Stefano Lattarini
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

[Stefano Lattarini]

Post by Peter Johansson
[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...

Post by Peter Johansson

Post by Stefano Lattarini
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).

Post by Peter Johansson
[BIG SNIP]

Regards,
Stefano

[Peter Rosin]

Post by Stefano Lattarini

Post by Peter Johansson
[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.

Post by Stefano Lattarini

Post by Peter Johansson

Post by Stefano Lattarini
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

[Stefano Lattarini]

Post by Peter Johansson
[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

[Stefano Lattarini]

Post by Stefano Lattarini

Post by Stefano Lattarini
* 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

[Miles Bader]

Post by Stefano Lattarini

Post by Stefano Lattarini

Post by Stefano Lattarini
* 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,

<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

[Stefano Lattarini]

Post by Miles Bader

Post by Stefano Lattarini

Post by Stefano Lattarini

Post by Stefano Lattarini
* 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,

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

Post by Miles Bader
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

Post by Miles Bader
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.

Post by Miles Bader
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

[Miles Bader]

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

[Mathieu Lirzin]

Hello,

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

[...]

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