Stable release?

[Matt Welsh]

I guess I don't understand the problem here. Isn't the Java-specific
portion of EGCS maintained by people *on this list*? What, then, is the
problem with making branded versions of EGCS/LIBGCJ available to people
on the GCJ website?

This situation is certainly hurting the GCJ project. GCJ is really getting
to the point where it's a powerful and robust Java compiler, but unfortunately
not many people know about it or use it -- perhaps because there's a lot
missing from the old version posted on the website. 

Also, the startup cost to start working with GCJ is too high. Making a 
clearly labelled "stable" GCJ version, all packaged up and ready to use, 
would go a long way towards solving this problem. Right now in order to use
GCJ you either get to (a) grab the old 2.95.1 release, (b) get 2.95.2 and
find some patches on a mysterious website referred to in one of Bryce's
postings to the mailing list months ago; or (c) sweat through grabbing the
latest CVS tree, which nobody knows whether it's broken or not.

I think we should do something about this situation *now*, rather than 
just "living with it" indefinitely. My suggestion is simply to provide 
a known-working snapshot of EGCS on the website. (Call it an "informal
snapshot", "beta release", or whatever ... the point is that we can't wait
for the EGCS team to decide that the whole damn compiler is ready for a 
release.) If people find bugs then they should first try the latest CVS 
version, with the understanding that the team will only accept patches 
against the latest version of the tree. LIBGCJ can be released on any cycle 
that we choose.

Also keep in mind that almost all of the bugs we're likely to run into are
in libgcj, NOT EGCS! The point of having a "branded" snapshot of EGCS that
we suggest that people use is just so they have the right compiler to support
later versions of libgcj. The Java support in the compiler itself isn't 
changing that much ... is it?

Matt