Re: [cygnus.egcs] GCC 3.0 Branch and Call For Volunteers

[Tom Tromey <tromey at redhat dot com>]

>> Comments?  Disagreements?  Suggestions?

Bryce> I don't think we need to be too strict about Java changes
Bryce> leading up to the release, at least for the runtime
Bryce> side. Certainly, big low level things like major classloader
Bryce> changes or the hash sync stuff could probibly wait till
Bryce> post-3.0, but in general I think most all fixes and updates for
Bryce> libgcj should go onto both the branch and the trunk until maybe
Bryce> a few days before the release. Otherwise we'll just end up with
Bryce> a release that is months behind the current cvs, which sucks.

Hopefully gcc 3.1 will come out on a quicker schedule than gcc 3.0.
And even more hopefully we'll see regular gcc releases so we don't end
up in the situation we have been in since 2.95.

At some point we have to stop making changes so the release can be
made.  I'm inclined to stop now and concentrate on fixing major bugs.

Regardless, I think we should have a backup plan in case gcc 3.1 (or
3.2, or ...) takes longer than expected.  I think we should plan for
compatibility with the most recent compiler, but not necessarily the
runtime.  That way we can make new libgcj releases on an independent
schedule.

So, for instance, if we need to make an incompatible change, we would
make sure that the runtime can always be compiled with the most recent
compiler.  Maybe we could do this by only making such changes on the
trunk, while continuing to put bug fixes on the release branch.

It might even be possible for us to do our own gcj/libgcj releases on
an independent schedule.  That would be even better because we
wouldn't have to worry as much about compatibility (at least if we
could keep the middle and back ends the same).

This will be more work for us, of course.  So I hope instead gcc can
make more frequent releases.

Tom