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
