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

[Stefano Lattarini]

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