[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 <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
- [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Stefano Lattarini, 2013/01/28
- Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Jack Kelly, 2013/01/28
- Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Thien-Thi Nguyen, 2013/01/29
- Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Peter Johansson, 2013/01/29
- Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Daniel Herring, 2013/01/29
- Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Eric Dorland, 2013/01/30
- Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Diego Elio Pettenò, 2013/01/31