Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/17/2013 03:57 PM, Stefano Lattarini wrote: On 02/13/2013 07:39 PM, Stefano Lattarini wrote: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578 OK, so far I've seen only positive feedback about this proposal. There are still some unresolved issues about how to handle beta releases; but the related proposals can be seen as a refinement of my scheme, not as something incompatible or in competition with it. So I see no reason to hold back the implementation of my proposal on their account: we can implement those refinements later, once some consensus is reached and the details are worked out. So, if I see no further objections, I'm going ahead with my proposal in a few days. Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as well as few miscellaneous comments in tests and scripts). Then we can finally proceed with the re-shuffling of the Git repository -- which I guess will also have to be announced in autotools-announce at least, as well as reported as a news on Savannah. So here is my attempt; OK to push to branch-1.13.2? I will proceed in a couple of days if there is no objection. Pushed now. Regards, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/21/2013 03:32 PM, Stefano Lattarini wrote: Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as well as few miscellaneous comments in tests and scripts). Then we can finally proceed with the re-shuffling of the Git repository -- which I guess will also have to be announced in autotools-announce at least, as well as reported as a news on Savannah. So here is my attempt; OK to push to branch-1.13.2? I will proceed in a couple of days if there is no objection. Pushed now. And here is the follow-up to fix some left-over references to the older versioning scheme in 'maint' (they were not present in 'branch-1.13.2'). Already pushed to 'maint'. In a couple of days, I will proceed with this branch moving: * branch-1.13.2 - maint * maint - master * master - next Regards, Stefano 8 8 8 8 8 8 8 8 8 From d5f83b89cc4d2da9078669018877b3bac5c2fadc Mon Sep 17 00:00:00 2001 Message-Id: d5f83b89cc4d2da9078669018877b3bac5c2fadc.1361458350.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Thu, 21 Feb 2013 15:52:22 +0100 Subject: [PATCH] maint: more adjustments to the new versioning scheme This is a follow-up to commit 'v1.13.1b-11-g97aaf12'. * automake.in: Adjust a comment. * PLANS: Adjust several files in here. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- PLANS/obsolete-removed/am-prog-mkdir-p.txt | 8 +++- PLANS/obsolete-removed/configure.in.txt| 10 +- PLANS/rm-f-without-args.txt| 10 +- PLANS/subdir-objects.txt | 10 +- PLANS/texi/drop-split-info-files.txt | 6 +++--- automake.in| 2 +- 6 files changed, 22 insertions(+), 24 deletions(-) diff --git a/PLANS/obsolete-removed/am-prog-mkdir-p.txt b/PLANS/obsolete-removed/am-prog-mkdir-p.txt index d5b7695..20d5cf5 100644 --- a/PLANS/obsolete-removed/am-prog-mkdir-p.txt +++ b/PLANS/obsolete-removed/am-prog-mkdir-p.txt @@ -1,6 +1,4 @@ -The macro AM_PROG_MKDIR_P is no longer going to be removed in Automake 1.14 -(and in fact, any plan to remove it evenatually has been dropped as well). - +The macro AM_PROG_MKDIR_P is no longer going to be removed from Automake. Let's see a bit of history to understand why. I had already scheduled the removal of the long-deprecated AM_PROG_MKDR_P @@ -46,14 +44,14 @@ out, and we lose. That already happened in practice: http://lists.gnu.org/archive/html/bug-grep/2013-01/msg3.html Moreover, while I might see it as not unreasonable to ask a developer -using Automake 1.14 to also update Gettext to 1.18.2, that would not +using Automake 2.0 to also update Gettext to 1.18.2, that would not be enough; in order for gettext to use the correct data files, that developer would have to update his configure.ac to read: AM_GNU_GETTEXT_VERSION([0.18.2]) thus requiring *all* of his co-developers to install Gettext 1.18.2, -even if they are still using, say, Automake 1.13. Bad. +even if they are still using, say, Automake 1.13 or 1.14. Bad. So I decided to re-instate this macro as a simple alias for AC_PROG_MKDIR_P (plus a non-fatal runtime warning in the 'obsolete' category), and drop diff --git a/PLANS/obsolete-removed/configure.in.txt b/PLANS/obsolete-removed/configure.in.txt index baed853..180f92c 100644 --- a/PLANS/obsolete-removed/configure.in.txt +++ b/PLANS/obsolete-removed/configure.in.txt @@ -13,16 +13,16 @@ present in the development version of autoconf so far (scheduled to become Autoconf 2.70). So ... -For Automake 1.14 -- +For Automake 2.0 + ... we have decided to wait until 2.70 is out before really removing 'configure.in' support. Since we plan to require Autoconf 2.70 in -Automake 1.14 (so that we can remove the hacky code emulating +Automake 2.0 (so that we can remove the hacky code emulating AC_CONFIG_MACRO_DIRS for older autoconf versions), we are quite sure that Autoconf will actually have started deprecating 'configure.in' -by the time Automake 1.14 is released. +by the time Automake 2.0 is released. Note that the removal of 'configure.in' has already been implemented -in our master branch (from where the 1.14 release will be finally +in our 'next' branch (from where the 2.0 release will be finally cut); see commits 'v1.13-17-gbff57c8' and 'v1.13-21-g7626e63'. diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt index 5362f98..918e049 100644 --- a/PLANS/rm-f-without-args.txt +++ b/PLANS/rm-f-without-args.txt @@ -21,20 +21,20 @@ the no-args rm -f usage is supported on the system configure is being run on; complain loudly if this is not the case, and tell the user to report the situation to us. -For Automake 1.14 -- +For Automake 2.0 + Make any failure in the configure-time probe check introduced by the previous point fatal; and in case
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/13/2013 07:39 PM, Stefano Lattarini wrote: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578 OK, so far I've seen only positive feedback about this proposal. There are still some unresolved issues about how to handle beta releases; but the related proposals can be seen as a refinement of my scheme, not as something incompatible or in competition with it. So I see no reason to hold back the implementation of my proposal on their account: we can implement those refinements later, once some consensus is reached and the details are worked out. So, if I see no further objections, I'm going ahead with my proposal in a few days. Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as well as few miscellaneous comments in tests and scripts). Then we can finally proceed with the re-shuffling of the Git repository -- which I guess will also have to be announced in autotools-announce at least, as well as reported as a news on Savannah. So here is my attempt; OK to push to branch-1.13.2? I will proceed in a couple of days if there is no objection. Thanks, Stefano 8 8 8 8 8 8 8 8 From 97aaf121e92767dc06385d020dd30cdfaa86126f Mon Sep 17 00:00:00 2001 Message-Id: 97aaf121e92767dc06385d020dd30cdfaa86126f.136789.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Sun, 17 Feb 2013 10:25:29 +0100 Subject: [PATCH] describe new versioning and branching scheme, and adjust to it See discussion about automake bug#13578 for more details and background. Basically, for the versioning scheme: - micro versions only for bug and regression fixing; - minor versions for new backward-compatible features, and new non-fatal deprecations; - major versions for backward-incompatibilities, complex new features, and major refactoring. And for the git branching scheme: + branch 'next' is for the upcoming major version; + branch 'master' is now for the upcoming minor version; + branch 'maint' is for the upcoming micro (bug-fixing) version; + the merging hierarchy is: 'maint' - 'master' - 'next'. * HACKING (Automake versioning and compatibility scheme): New. (Working with git): Adjust. * NEWS: Update and fix. * aclocal.in: Adjust some FIXME messages. * automake.in: Likewise. * m4/mkdirp.m4: Likewise. * t/aclocal-acdir.sh: Likewise. * t/aclocal-macrodir.tap: Likewise. * t/aclocal-macrodirs.tap: Likewise. * lib/Automake/Options.pm: Likewise. * m4/internal/ac-config-macro-dirs.m4: Likewise. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- HACKING | 100 +--- NEWS| 59 + aclocal.in | 8 +-- automake.in | 12 +++-- lib/Automake/Options.pm | 4 +- m4/internal/ac-config-macro-dirs.m4 | 2 +- m4/mkdirp.m4| 3 +- t/aclocal-acdir.sh | 2 +- t/aclocal-macrodir.tap | 2 +- t/aclocal-macrodirs.tap | 2 +- 10 files changed, 150 insertions(+), 44 deletions(-) diff --git a/HACKING b/HACKING index c70143e..604bf67 100644 --- a/HACKING +++ b/HACKING @@ -93,6 +93,48 @@ code without. += Automake versioning and compatibility scheme + +* There are three kinds of automake releases: + +- new major releases (e.g., 2.0, 5.0) +- new minor releases (e.g., 1.14, 2.1) +- micro a.k.a. bug-fixing releases (e.g., 1.13.2, 2.0.1, 3.5.17). + + A new major release should have the major version number bumped, and + the minor and micro version numbers reset to zero. A new minor release + should have the major version number unchanged, the minor version number + bumped, and the micro version number reset to zero. Finally, a new + micro version should have the major and minor version numbers unchanged, + and the micro version number bumped. + + For example, the first minor version after 1.13.2 will be 1.14; the + first bug-fixing version after 1.14 that will be 1.14.1; the first + new major version after all such releases will be 2.0; the first + bug-fixing version after 2.0 will be 2.0.1; and a further bug-fixing + version after 2.0.1 will be 2.0.2. + +* Micro releases 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 by them. + +* Minor releases 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
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Hi Diego. On 02/12/2013 06:50 PM, Diego Elio Pettenò wrote: On 12/02/2013 17:44, Stefano Lattarini wrote: Ah, ok, so in the end you already agree that this is a documentation issue rather than a versioning one. Please correct me if I'm wrong! I guess it's a matter of perception. I honestly don't see the point of beta software if nobody's using it, as it would just actually be an alpha for the beta (.0/.1 releases) which then becomes stable (.2+ — sometimes). If we go with a new major version we could have: 2.0.x - new major, testing branch (let's not call it beta!), all fine but it throws a huge warning at runtime that the branch is not finalized yet and thus that it should not be used for distributed software 2.1.x - new major, stable branch, micro versions for bugfix only 2.2.x - new major, new features branch, introduces deprecation warnings for features leaving in 3.0, possibly some opt-in versions of features becoming standard in 3.0. _If needed_ only: 2.90.x - experimental branch for the upcoming 3.0 testing branch The scheme you are proposing seems sensible to me. Anyway, it is an *extension* to my new proposed versioning/branching scheme, so we don't have to decide on its adoption right away -- we can switch to my proposed scheme first, and then refine/enhance it with your proposal, if nobody objects. OK? Thanks, Stefano
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Hi Miles. On 02/12/2013 12:50 AM, Miles Bader wrote: Stefano Lattarini stefano.lattar...@gmail.com 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, ... Yuck; the new versioning scheme is done exactly to avoid that kind of overly long version numbers -- otherwise, we could just have 1.13.1.1 as bug-fixing release, 1.13.2 as new minor release, and 1.14 as new major release. But if that leading 1 is going to remain unchanged anyway, what is the point of keeping it? It's just visual noise IMO. (In addition, the current version-checking code in Automake only grasps version numbers with at most three numbers). Or the widely used in FOSS 1.13.99... [sometimes they start at 90, to leave room for updates, This might work. But see below. but I suppose you could always just use .99.1, .99.2, ...] (No, because, as said above, I don't want to have version numbers with four or more components) Anyway, before changing the current naming scheme for beta versions, we'd need some numbers about which the most widespread naming schemes are, and weight their advantages and disadvantages w.r.t. our workflow; we don't want to trade the current naming scheme for another that is only marginally more popular, or for a one that will give use a new and bigger set of problems down the road. Thanks, Stefano
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com: Mostly fair points; but the biggest issue with this proposal (not sure why I didn't think of it before, sorry) is that it is not at all clear that a version like 1.13.0.1 is supposed to be a beta release. People will easily mistake it for a stable release. How about this: pick whatever scheme you like for other reasons, and then add -beta to those version numbers. In other words, a purely informational suffix, which is not actually necessary for version sorting... (note that the a, b, etc, suffixes have the same issue) -miles -- Cat is power. Cat is peace.
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Hi Miles. On 02/12/2013 12:50 AM, Miles Bader wrote: Stefano Lattarini stefano.lattar...@gmail.com 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, ... Yuck; the new versioning scheme is done exactly to avoid that kind of overly long version numbers -- otherwise, we could just have 1.13.1.1 as bug-fixing release, 1.13.2 as new minor release, and 1.14 as new major release. But if that leading 1 is going to remain unchanged anyway, what is the point of keeping it? It's just visual noise IMO. (In addition, the current version-checking code in Automake only grasps version numbers with at most three numbers). Or the widely used in FOSS 1.13.99... [sometimes they start at 90, to leave room for updates, This might work. But see below. but I suppose you could always just use .99.1, .99.2, ...] (No, because, as said above, I don't want to have version numbers with four or more components) Anyway, before changing the current naming scheme for beta versions, we'd need some numbers about which the most widespread naming schemes are, and weight their advantages and disadvantages w.r.t. our workflow; we don't want to trade the current naming scheme for another that is only marginally more popular, or for a one that will give use a new and bigger set of problems down the road. Thanks, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/11/2013 04:00 PM, Diego Elio Pettenò wrote: 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, Why not? and 1.13.0 _and_ .1 were not really final releases, This is true, but is only due to the fact that I released them with too much haste, without giving time for proper testing. IOW, this debacle has been a fault of mine, not of the naming scheme. I would suggest calling the first beta as 1.14.0 with the big fat warning, I don't see any need for this; everyone knows that a new major release is more likely to contain bugs and rough edges. (OTOH, this is not excuse to be sloppy and hastily in the release process as I've been for 1.13; but avoiding repeating the mistake in the future will only require more care and attention from the maintainer, and not a change of policy). 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, Any link about this? The info I found on Google doesn't seem very helpful nor relevant. and leads to decency, I'd say. Thanks, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com: 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, ... Yuck; the new versioning scheme is done exactly to avoid that kind of overly long version numbers Well, I agree in general that too many components is yucky, but keep in mind that these _aren't releases_, so assigning them awkward version numbers doesn't really seem all that annoying. These really aren't part of the historical record. The existing naming scheme for betas does the same thing (uses weird version numbers), but is problematic because it's not mechanically consistent with ordinary version numbers (and so screws up cases such as packaging software). I do agree that removing the leading 1. might be a good idea if it's meaningless in practice. Linux's similar action was good. -miles -- Cat is power. Cat is peace.
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/12/2013 09:25 AM, Miles Bader wrote: 2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com: 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, ... Yuck; the new versioning scheme is done exactly to avoid that kind of overly long version numbers Well, I agree in general that too many components is yucky, but keep in mind that these _aren't releases_, so assigning them awkward version numbers doesn't really seem all that annoying. These really aren't part of the historical record. The existing naming scheme for betas does the same thing (uses weird version numbers), but is problematic because it's not mechanically consistent with ordinary version numbers (and so screws up cases such as packaging software). Mostly fair points; but the biggest issue with this proposal (not sure why I didn't think of it before, sorry) is that it is not at all clear that a version like 1.13.0.1 is supposed to be a beta release. People will easily mistake it for a stable release. OK, we can add warnings and info and whatnot in the manual and homepage of automake about our unusual versioning scheme, but how many people will read them? And in the end, even those who do will likely be just annoyed by the fact that we are trying to be clever and invent a new versioining scheme incompatible with every other existing one. No, if we want to change the versioning scheme for beta and rc versions, we want the new scheme to be already used and well known. I do agree that removing the leading 1. might be a good idea if it's meaningless in practice. Linux's similar action was good. -miles -- Cat is power. Cat is peace. Thanks, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com: Mostly fair points; but the biggest issue with this proposal (not sure why I didn't think of it before, sorry) is that it is not at all clear that a version like 1.13.0.1 is supposed to be a beta release. People will easily mistake it for a stable release. How about this: pick whatever scheme you like for other reasons, and then add -beta to those version numbers. In other words, a purely informational suffix, which is not actually necessary for version sorting... (note that the a, b, etc, suffixes have the same issue) -miles -- Cat is power. Cat is peace.
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On Tue, Feb 12, 2013 at 9:38 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On 02/12/2013 09:25 AM, Miles Bader wrote: 2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com: 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, ... Yuck; the new versioning scheme is done exactly to avoid that kind of overly long version numbers Well, I agree in general that too many components is yucky, but keep in mind that these _aren't releases_, so assigning them awkward version numbers doesn't really seem all that annoying. These really aren't part of the historical record. The existing naming scheme for betas does the same thing (uses weird version numbers), but is problematic because it's not mechanically consistent with ordinary version numbers (and so screws up cases such as packaging software). Mostly fair points; but the biggest issue with this proposal (not sure why I didn't think of it before, sorry) is that it is not at all clear that a version like 1.13.0.1 is supposed to be a beta release. People will easily mistake it for a stable release. OK, we can add warnings and info and whatnot in the manual and homepage of automake about our unusual versioning scheme, but how many people will read them? And in the end, even those who do will likely be just annoyed by the fact that we are trying to be clever and invent a new versioining scheme incompatible with every other existing one. No, if we want to change the versioning scheme for beta and rc versions, we want the new scheme to be already used and well known. in our project, we append _beta and _rc (or _rc1, _rc2 etc...) for beta and release candidate. It's sufficiently explicit. For example, 1.14.0_beta Vincent Torri
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
* On 2013 12 Feb 03:08 -0600, Vincent Torri wrote: in our project, we append _beta and _rc (or _rc1, _rc2 etc...) for beta and release candidate. It's sufficiently explicit. For example, 1.14.0_beta I was advised by a Debian maintainer to use tilde '~' as the separator as any text following it will be considered older. For example, in our project 'Hamlib-3.0~git' is older than 'Hamlib-3.0' will be once released. A hyphen or underscore trips this logic up, as I understand it, for both .deb and .rpm formats. While this is good practice from a package mainter's POV, it has not been a problem as we ask that such code not be packaged by distributions. The extra text is a human convenience add-on. Also, the practice of using the prior released version number as the base for the next version's beta is a bit confusing to me. The Linux kernel model of the *next* planned release tagged with an additional rc1, beta, git, what-have-you always seemed more logical to me, at least. Our project adopted this approach of versioning of base +1 (always arbitrary) for the next planned released so that beta testers and developers are well aware of the next planned version and that additional characters following a '~' means a yet to be released version. In other words, 1.14~git, 1.14~beta, 1.14~rc1, make more sense to me for the forthcoming 1.14 release than using 1.13+whatever which magically is promoted to 1.14 upon release. JMHO. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 12/02/2013 09:26, Stefano Lattarini wrote: Given that 1.12.0 was not really final release, Why not? AM_PROG_MKDIR_P. This is true, but is only due to the fact that I released them with too much haste, without giving time for proper testing. IOW, this debacle has been a fault of mine, not of the naming scheme. True, but it shows a pattern: most people (even developers who get involved in the process, such as Paolo) do not even look at the beta versions.. I don't see any need for this; everyone knows that a new major release is more likely to contain bugs and rough edges. (OTOH, this is not excuse to be sloppy and hastily in the release process as I've been for 1.13; but avoiding repeating the mistake in the future will only require more care and attention from the maintainer, and not a change of policy). True, but a new beta also is also more likely to contain bugs and rough edges... so it's basically the same thing, thus why I'm saying that it should just be the same. Put out the new major at not stable yet, try it out all around, then make a release to call it stable. Any link about this? The info I found on Google doesn't seem very helpful nor relevant. I'm afraid I don't have anything that Google wouldn't have. But at least for 2.2, it was declared stable much later than .0 if I'm not mistaken. Basically, it would be like making policy that the new major branch is not stable until we say it is.. which is really what we need. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Nate Bargmann n...@n0nb.us writes: I was advised by a Debian maintainer to use tilde '~' as the separator as any text following it will be considered older. For example, in our project 'Hamlib-3.0~git' is older than 'Hamlib-3.0' will be once released. A hyphen or underscore trips this logic up, as I understand it, for both .deb and .rpm formats. This is a Debian-specific syntax, for use in Debian package version numbers. It's a handy way for the Debian maintainer to directly represent various existing package version naming schemes with only mechanical changes (typical, replacing a _ or - with ~), but I don't think there's any intent that upstreams should adopt this syntax directly (though I suppose it doesn't particularly hurt if they do...). -miles -- Abstainer, n. A weak person who yields to the temptation of denying himself a pleasure. A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
I like the -alpha/-beta/-rcN markings. As someone who often tracks cutting-edge stuff, it is nice to have a clear indicator of how stable the author things something is. This info helps the user do a quick cost/benefit estimate when deciding what version to use today. - Daniel
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/12/2013 04:15 PM, Diego Elio Pettenò wrote: On 12/02/2013 09:26, Stefano Lattarini wrote: Given that 1.12.0 was not really final release, Why not? AM_PROG_MKDIR_P. Ah, right. I had forgot about that (selective memory? A dangerous thing). This is true, but is only due to the fact that I released them with too much haste, without giving time for proper testing. IOW, this debacle has been a fault of mine, not of the naming scheme. True, but it shows a pattern: most people (even developers who get involved in the process, such as Paolo) do not even look at the beta versions.. That is not something automake can do anything about. Releasing beta versions whose version numbers suggests they are actually stable versions is a solution worse than the problem. But you might correctly point out that, due to lack of proper testing, this is already what we are doing right now (albeit not by choice); so the issue becomes at this point a documentation issue (that is, we should find a way to inform the users that early stable versions of new major releases might turn out to be lamentably unstable in practice, if nobody has given the betas proper testing). See again below. I don't see any need for this; everyone knows that a new major release is more likely to contain bugs and rough edges. (OTOH, this is not excuse to be sloppy and hastily in the release process as I've been for 1.13; but avoiding repeating the mistake in the future will only require more care and attention from the maintainer, and not a change of policy). True, but a new beta also is also more likely to contain bugs and rough edges... so it's basically the same thing, thus why I'm saying that it should just be the same. Put out the new major at not stable yet, try it out all around, then make a release to call it stable. This sounds sensible, but I think it should be done in addition to the usual release of classic beta versions (with the hope that someone will get to testing them eventually). And if we agree on this approach, the only required change would be a new section about this versioning and stability issues in the Automake manual (and/or in the Autotools Mythbuster guide). As usual, patches are welcome (this is not really my itch). Any link about this? The info I found on Google doesn't seem very helpful nor relevant. I'm afraid I don't have anything that Google wouldn't have. But at least for 2.2, it was declared stable much later than .0 if I'm not mistaken. That happened with Python as well, and I guess with many other softwares who did a major version bump with non-trivial backward incompatibilities. Basically, it would be like making policy that the new major branch is not stable until we say it is.. which is really what we need. Ah, ok, so in the end you already agree that this is a documentation issue rather than a versioning one. Please correct me if I'm wrong! Thanks, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 12/02/2013 17:44, Stefano Lattarini wrote: Ah, ok, so in the end you already agree that this is a documentation issue rather than a versioning one. Please correct me if I'm wrong! I guess it's a matter of perception. I honestly don't see the point of beta software if nobody's using it, as it would just actually be an alpha for the beta (.0/.1 releases) which then becomes stable (.2+ — sometimes). If we go with a new major version we could have: 2.0.x - new major, testing branch (let's not call it beta!), all fine but it throws a huge warning at runtime that the branch is not finalized yet and thus that it should not be used for distributed software 2.1.x - new major, stable branch, micro versions for bugfix only 2.2.x - new major, new features branch, introduces deprecation warnings for features leaving in 3.0, possibly some opt-in versions of features becoming standard in 3.0. _If needed_ only: 2.90.x - experimental branch for the upcoming 3.0 testing branch -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Hi Diego, Jack, sorry for the late reply. On 02/01/2013 06:47 AM, Jack Kelly wrote: Diego Elio Pettenò flamee...@flameeyes.eu 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
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Stefano Lattarini stefano.lattar...@gmail.com 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
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Diego Elio Pettenò flamee...@flameeyes.eu 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
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Diego Elio Pettenò flamee...@flameeyes.eu 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
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Diego Elio Pettenò flamee...@flameeyes.eu 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
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
* Stefano Lattarini (stefano.lattar...@gmail.com) 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
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 01/29/2013 08:09 AM, Thien-Thi Nguyen wrote:
() Stefano Lattarini stefano.lattar...@gmail.com
() 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
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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
[IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
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
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Stefano Lattarini stefano.lattar...@gmail.com 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
