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

classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

bug#13578: [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



Reply | Threaded
Open this post in threaded view
|

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

Jack Kelly-4
Stefano Lattarini <[hidden email]> writes:

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

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



Reply | Threaded
Open this post in threaded view
|

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

Thien-Thi Nguyen-6
In reply to this post by Stefano Lattarini
() Stefano Lattarini <[hidden email]>
() 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.

--
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Peter Johansson-6
In reply to this post by Stefano Lattarini
Hi Stefano,


On 1/29/13 5:48 AM, Stefano Lattarini wrote:

> 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.
Will it still be linear, or do you expect any 1.x release after 2.0?

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


> 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

--
Peter Johansson




Reply | Threaded
Open this post in threaded view
|

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

goodell (Bugzilla)
On Jan 29, 2013, at 6:18 AM CST, Peter Johansson wrote:

> On 1/29/13 5:48 AM, Stefano Lattarini wrote:
>
>> 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




Reply | Threaded
Open this post in threaded view
|

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

Stefano Lattarini
In reply to this post by Peter Johansson-6
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



Reply | Threaded
Open this post in threaded view
|

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

Stefano Lattarini
In reply to this post by Thien-Thi Nguyen-6
On 01/29/2013 08:09 AM, Thien-Thi Nguyen wrote:
> () Stefano Lattarini <[hidden email]>
> () 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)
>
Fully agreed; and abridged version of this proposal is to land in HACKING
soon(ish).

> and methodically use them in the ChangeLog entries.
>
This would be overkill IMVHO.

> 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.
>
Again, +1

>    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



Reply | Threaded
Open this post in threaded view
|

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

Daniel Herring
In reply to this post by Stefano Lattarini
On Mon, 28 Jan 2013, Stefano Lattarini wrote:

> 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



Reply | Threaded
Open this post in threaded view
|

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

Eric Dorland
In reply to this post by Stefano Lattarini
* Stefano Lattarini ([hidden email]) wrote:

> 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.
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
release within that major (eg package automake-2 @ version 2.1.3,
automake-3 @ version 3.0.4).

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

> 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
>
--
Eric Dorland <[hidden email]>
ICQ: #61138586, Jabber: [hidden email]


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Diego Elio Pettenò-2
In reply to this post by Stefano Lattarini
On 28/01/2013 20:48, Stefano Lattarini wrote:
> 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).

--
Diego Elio Pettenò — Flameeyes
[hidden email]http://blog.flameeyes.eu/



Reply | Threaded
Open this post in threaded view
|

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

Stefano Lattarini
In reply to this post by Eric Dorland
On 01/30/2013 10:07 PM, Eric Dorland wrote:
>
> [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
> release within that major (eg package automake-2 @ version 2.1.3,
> automake-3 @ version 3.0.4).
>
> [SNIP PROPOSAL for new branching scheme]
>
>> 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



Reply | Threaded
Open this post in threaded view
|

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

Stefano Lattarini
In reply to this post by Diego Elio Pettenò-2
Hi Diego.

On 01/31/2013 12:46 PM, Diego Elio Pettenò wrote:
> On 28/01/2013 20:48, Stefano Lattarini wrote:
>> 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
> 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;
>
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



Reply | Threaded
Open this post in threaded view
|

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

Stefano Lattarini
In reply to this post by Daniel Herring
On 01/30/2013 04:30 AM, Daniel Herring wrote:

> On Mon, 28 Jan 2013, Stefano Lattarini wrote:
>
>> 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.

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

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

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

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

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

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

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

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

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

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

>
> Hope that helps,
> Daniel

Thanks,
  Stefano



Reply | Threaded
Open this post in threaded view
|

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

Diego Elio Pettenò-2
In reply to this post by Stefano Lattarini
On 31/01/2013 13:47, Stefano Lattarini wrote:
> 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?

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.

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

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

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

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

--
Diego Elio Pettenò — Flameeyes
[hidden email]http://blog.flameeyes.eu/



Reply | Threaded
Open this post in threaded view
|

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

Jack Kelly-4
Diego Elio Pettenò <[hidden email]> writes:
> 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



Reply | Threaded
Open this post in threaded view
|

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

Diego Elio Pettenò-2
On 31/01/2013 20:58, Jack Kelly wrote:
> 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.

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

--
Diego Elio Pettenò — Flameeyes
[hidden email]http://blog.flameeyes.eu/



Reply | Threaded
Open this post in threaded view
|

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

Jack Kelly-4
Diego Elio Pettenò <[hidden email]> writes:
> On 31/01/2013 20:58, Jack Kelly wrote:
>> 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?

> KDE 4.0 was a screwup because there was no big fat warning, and users
> insisted to have it. No user _asks_ for automake.
>
>> 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



Reply | Threaded
Open this post in threaded view
|

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

Stefano Lattarini
Hi Diego, Jack, sorry for the late reply.

On 02/01/2013 06:47 AM, Jack Kelly wrote:

> Diego Elio Pettenò <[hidden email]> writes:
>> On 31/01/2013 20:58, Jack Kelly wrote:
>>> 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?
>
>> KDE 4.0 was a screwup because there was no big fat warning, and users
>> insisted to have it. No user _asks_ for automake.
>>
>>> 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





Reply | Threaded
Open this post in threaded view
|

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

Diego Elio Pettenò-2
On 11/02/2013 15:54, Stefano Lattarini wrote:
> 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.

--
Diego Elio Pettenò — Flameeyes
[hidden email]http://blog.flameeyes.eu/



Reply | Threaded
Open this post in threaded view
|

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

Miles Bader-2
In reply to this post by Stefano Lattarini
Stefano Lattarini <[hidden email]> writes:
> 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

--
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde



1234