Re: Beyond GCC 3.0: Summing Up

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <20010710100049.F19026@lucon.org> you write:

>There is a difference. I am suggesting make more bug fix releases so
>that a Linux/xxxBSD distribution can build the whole distribution
>with the current major release within a build cycle using a new gcc,
>which may take weeks or months. Within that cycle, they are testing
>a major gcc release, which consists of the .0 release and consequent
>.0.x releases. Their goal is to find a reliable .0.x release which
>can build the whole distribution. If the current release doesn't work
>and takes too long for the next .0.x release, I don't they will even
>try the new gcc.

I don't know as for others, but this is already the case in OpenBSD land.
We released 2.9 in june. There's absolutely no doubt the december release
won't be compiled with the  gcc 3.0 branch. There are too many architectures
to make work for that to be achievable. And the compiler is a large enough
subsystem, and important enough, that the import would have to happen now
for this to have a chance to succeed... which means that gcc 3.0 would have
had to have been tested for two months already, as far as our tree is 
concerned. (we have this policy that all architectures use the same tools
as far as possible... which includes i386, m68k, m88k, sparc, vax, ppc, 
alpha and others)

So, by the time we get around to using the 3.0 branch, I hope there will have
been a few bug-fix releases already... which is why a maintained gcc-stable
branch with minor releases is important for us. You may remember I was
pushing for gcc 2.95.3 a little while back.