Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

[Stefano Lattarini]

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

> [SNIP]
>
> Stefano Lattarini wrote:
>
>> So I propose the following change in the Automake versioning scheme:
>>
>>    * Major releases should actually have the major version number bumped.
>>      That is, the next major Automake version will be 2.0, rather than
>>      1.14; and the major version after that will be 3.0; and so on.
>>      After all, there is no shortage of integer numbers to use :-)
>>      Such major releases can introduce backward-incompatibilities (albeit
>>      such incompatibilities should be announced well in advance, and a
>>      smooth transition plan prepared for them), and try more risking
>>      and daring refactorings.
>>
>>    * Minor releases have the minor version number bumped (1.13 ->  1.14
>>      ->  1.15 ...), can introduce new "safe" features, do non-trivial
>>      but mostly safe code clean-ups, and even add new runtime warnings
>>      (rigorously non-fatal); but they shouldn't include any backward
>>      incompatible change, nor contain any potentially destabilizing
>>      refactoring or sweeping change, nor introduce new features whose
>>      implementation might be liable to cause bugs or regressions in
>>      existing code.
>
> Will it still be linear, or do you expect any 1.x release after 2.0?
>
Ideally, it should still be linear.  We could easily create an 'old-release'
branch from the last 1.x release, and backport  bug fixes implemented in
the 2.x series there; but I'd rather not do so, unless there is a strong
demand from the user base.

>>    * Micro releases (1.14.1, 1.14.2, ...) should be just bug-fixing
>>      releases; no new features should be added, and ideally, only
>>      trivial bugs, recent regressions, or documentation issues should
>>      be addressed here.
>>
> IMVHO, this is how it always has been, except the last year or so.
>
Yes, my bad there, sorry.  This is an attempt to remedy to it, and
improve the release scheme a little in the process.

> See for example release of Automake 1.10.2, which only fixed a couple
> of bugs. Change of behaviour (like recursive cleaning mentioned above)
> or optimizing the code never belong in a micro release. I'm glad you
> clarify this.
>
I should have probably done it earlier.  Well, better late then never.

>> Another plus of this new versioning scheme is that it will allow
>> different minor releases, even with the same major version, to
>> co-exist on the same system (that's because the $(APIVERSION)
>> variable will get bumped with each minor version now).
> 
> Why is that a plus? What is the use case when I want to keep on
> using Automake 2.1 after I have installed Automake 2.2?
>
The fact that a change like the "recursive cleaning" mentioned above
might have broken, in 2.2, some tricky usages in your makefiles, usages
that used to work in 2.1; and you might not want (or be able to) adjust
them right away.

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

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

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

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

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

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

> the future series of versions would look something like:
>
> 2.0
> 2.0.1
> 2.0.2
> 2.1
> 3.0
> 3.0.1
> 4.0
> ...
> In other words if the minor releases are rare, the middle digit
>  has no function and it could be removed with no loss:
>
> 2.0     -> 2.0
> 2.0.1  -> 2.1
> 2.0.2  -> 2.2
> 2.1     -> 3.0
> 3.0     -> 4.0
> 3.0.1  -> 4.1
> 4.0     -> 5.0
>
The whole point of this proposal is that minor releases (not merely
bug-fixing ones) have been proving to be quite common recently :-)

> or just keep the scheme as is
> 1.14
> 1.14.1
> 1.14.2
> 1.15
> 1.16
> 1.16.1
> 1.17
> 
> 
> Cheers,
> Peter
> 

Thanks,
  Stefano