[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, an
From: |
Diego Elio Pettenò |
Subject: |
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository |
Date: |
Thu, 31 Jan 2013 12:46:08 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 |
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
address@hidden — http://blog.flameeyes.eu/
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, (continued)
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Jack Kelly, 2013/01/28
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Thien-Thi Nguyen, 2013/01/29
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Peter Johansson, 2013/01/29
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Daniel Herring, 2013/01/30
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Eric Dorland, 2013/01/30
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository,
Diego Elio Pettenò <=