Re: release schedule for 1.9? (Was: Re: automake -vs- huge projects (1st patch))
On Thu, Jan 22, 2004 at 04:54:33PM -0700, Tom Tromey wrote: > > "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > > adl> Also, since we have switched to API-numbering, bumping that > adl> version number has a cost. For instance Debian distributes > adl> automake1.4, automake1.6, automake1.7, and automake1.8. If we > adl> add another API, it'd better be worth it. > > Yeah. It turns out that Red Hat still ships 1.5 because some packages > still depend on it. Sigh. Obviously this doesn't scale -- at some > point it has to be so painless to upgrade that someone like Debian or > Red Hat can simply ditch 1.x and convert everything to 1.x+1 all at > once. Frankly, the reason Debian is carrying so many versions is because maintainers are bloody lazy. Every transition of this form takes ages, no matter how easy it is to convert. Half the time there's nothing that needs to be done aside from actually using a newer version, and it still doesn't get done. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: release schedule for 1.9? (Was: Re: automake -vs- huge projects (1st patch))
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> Also, since we have switched to API-numbering, bumping that adl> version number has a cost. For instance Debian distributes adl> automake1.4, automake1.6, automake1.7, and automake1.8. If we adl> add another API, it'd better be worth it. Yeah. It turns out that Red Hat still ships 1.5 because some packages still depend on it. Sigh. Obviously this doesn't scale -- at some point it has to be so painless to upgrade that someone like Debian or Red Hat can simply ditch 1.x and convert everything to 1.x+1 all at once. adl> Maybe we could release an "official snapshot" of HEAD? This may adl> also help to better test these uncertain subdir-suffix-rules. adl> Would that be enough? It might. Unfortunately I don't think we can unilaterally make a decision like this. We'll have to involve the other gcc maintainers. I think the ideal for gcc is to have the entire tree requiring a single released version of automake. But, we'll never know if we can do it until we try :-) Tom
release schedule for 1.9? (Was: Re: automake -vs- huge projects (1st patch))
>>> "Thomas" == Thomas Fitzsimmons <[EMAIL PROTECTED]> 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
