[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMPORTANT] A new versioning scheme for automake releases, and a new

From: Diego Elio Pettenò
Subject: Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Date: Thu, 31 Jan 2013 15:58:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2

On 31/01/2013 13:47, Stefano Lattarini wrote:
> But there is already such a discussion going on; see:
>   <>
> 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 scripts
(the moment when 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
address@hidden —

reply via email to

[Prev in Thread] Current Thread [Next in Thread]