[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases

From: Stefano Lattarini
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Date: Tue, 29 Jan 2013 19:32:19 +0100

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

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

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

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

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

> Assuming 2.2 is 100% backward compatible
That cannot be guaranteed, as some bug fixes might break some corner-case
usages (especially when bugs were being used as features, through no fault
or abuse of the user; see for example <>); 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

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]