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/
