This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
release schedule for 1.9? (Was: Re: automake -vs- huge projects(1st patch))
- From: Alexandre Duret-Lutz <adl at src dot lip6 dot fr>
- To: Thomas Fitzsimmons <fitzsim at redhat dot com>
- Cc: Automake List <automake at gnu dot org>
- Date: Tue, 20 Jan 2004 22:43:14 +0100
- Subject: release schedule for 1.9? (Was: Re: automake -vs- huge projects(1st patch))
- References: <87pteopv13.fsf@fleche.redhat.com><2003-12-16-23-33-32+29787+duret_g@lrde.epita.fr><87llpcmdbp.fsf@fleche.redhat.com> <87wu8v22u3.fsf@src.lip6.fr><2003-12-28-03-25-05+12277+duret_g@lrde.epita.fr><1072822014.19216.310.camel@tortoise.toronto.redhat.com><87r7yi58ud.fsf@fleche.redhat.com><1074195217.2968.177.camel@tortoise.toronto.redhat.com>
>>> "Thomas" == Thomas Fitzsimmons <fitzsim@redhat.com> writes:
[...]
Thomas> I was wondering about the time frame for the next
Thomas> release of automake. Our libgcj configury upgrade
Thomas> depends on changes that are currently only available in
Thomas> automake's CVS HEAD, so we anxiously await an official
Thomas> version that includes those changes :)
No idea.
My instinct says to wait for 1.8.x to spread and stabilize. (By
"stabilize" I mean that no more regression against 1.7.x are
reported.)
Also, since we have switched to API-numbering, bumping that
version number has a cost. For instance Debian distributes
automake1.4, automake1.6, automake1.7, and automake1.8. If we
add another API, it'd better be worth it.
Finally, the `libtool --tag' support (presently on HEAD), makes
us dependent upon the next release of Autoconf. This is a
caching issue: Autoconf needs to know what --trace Automake will
use, so it can fill its cache beforehand. Technically you _can_
use CVS Automake without CVS Autoconf, but it will be slower.
Maybe we could release an "official snapshot" of HEAD? This may
also help to better test these uncertain subdir-suffix-rules.
Would that be enough?
--
Alexandre Duret-Lutz