On Wed, Jan 02, 2008 at 10:34:37PM -0800, Bernard Li wrote: > > On 12/31/07, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > > > while preparing a bootstrap environment which could be used to generate > > maintenance releases for the 3.0.x branch noticed we'd been using different > > versions for autotools that the ones detailed in README.SVNusers (which > > match the ones used by 2.5.7), as shown by the following table : > > > > --------------------------------------------------------------------- > > | | 2.5.7 | 3.0.0 | 3.0.1 | 3.0.2 .. 3.0.4 | 3.0.5 | 3.0.6 | > > |-------------------------------------------------------------------| > > | automake | 1.6.3 | 1.6.3 | 1.6.3 | 1.9.5 .. 1.9.5 | 1.9.6 | 1.9.2 | > > | autoconf | 2.53 | 2.57 | 2.57 | 2.59 .. 2.59 | 2.59 | 2.59 | > > | libtool | 1.4.2 | 1.5.8 | 1.5.8 | 1.5.8 .. 1.5.8 | 1.5.8 | 1.5.8 | > > --------------------------------------------------------------------- > > > > Should the documentation be updated?, and which are the recommend versions > > to use that are supported in all development workstations? > > > > Carlo > > I just build/release on whatever system I have easy access to (right > now it happens to be CentOS 4.x),
ok, will use CentOS 4.x then as a starting point for the maintenance releases for 3.0.x, since at least I can (sorta) replicate 3.0.6 > it matches the versions that are > referenced in the README.SVNusers file (i.e. versions used are >= > versions on the file). I believe the minimum version numbers > referenced in the file are still valid. the minimum version numbers should reflect IMHO the minimum common denominator for all supported architectures and preferably be the ones used to make the release packages, that way we are always sure that there won't be any autotools related issues in those packages and that they build and work correctly in all supported architectures. I have no access to those old versions but have an old RHEL 3.9 box (no subversion) with : automake: 1.6.3 autoconf: 2.57 libtool: 1.4.3 and will try to get a bootstrap tested there if possible (which then will need to be tested in all supported architectures to validate them) I really think would be easier just to update to the newer versions than to deal with any regressions they might trigger. > If this is an issue, please let me know. since we haven't done a release using those versions for several years a bootstrap using them might not be able to generate a valid release package for some architectures (Linux/MIPS and OpenBSD come to mind) for some other architectures (DragonflyBSD) even newer versions that the ones currently in use might be required. since (at least for 3.0.x) the srclib directory is pre-configured there is also an upper limit to which version can be used (my Gentoo Linux 2007.0 amd64 workstation using libtool 1.5.24 won't be able to generate a valid bootstrap because of that). Carlo ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
