3.3 branch, 3.3.1, 3.4, etc

[Tom Tromey <tromey at redhat dot com>]

For those who aren't aware, Mark made the 3.3 branch recently.  From
this I gather that the 3.3 release is a couple months away.  This is
great news for us, because gcj 3.3 is going to have many more features
than 3.2 had.  Also, it lets us start working on major features for
3.4.

There are still a number of bugs I want to have fixed before 3.3
ships.  My current list:

* Interpreter race conditions with direct threaded code
  (Fix: resolve while compiling the threading structure.)
* Resolve the org.w3c.* issues and implement whatever we decide.
  Currently this is "remove org.w3c.*, solve in rhug".
* Fix the bytecode verifier bugs (this is a maybe).
* Ensure StringTokenizer bug is fixed.
  (I thought it was but recent tests say otherwise...)
* Possible permission checking bugs in resolve.cc
  (See note from Per on patches list last week)
* Class loader fixes (going in tonight or tomorrow)
* PR 8955, 8866 (both `switch' related)
* Consider java.util.prefs import (low risk... worth it?)
* Resolve PR 8933 one way or the other
* Update libtool version info

I'll try to get these all in Gnats and make sure everything is marked
appropriately.  Comments on this list, suggestions for additions or
removals, etc, welcome.


I think our release criteria should be:

* Work on all platforms supported by 3.2, plus whatever new platforms
  make sense (S/390, SH, x86-64 -- assuming we can find testers)
* Pass test suite with 0 FAIL (mostly this means XFAILing tests we
  know we won't fix).  This includes Mauve and Jacks (with suitable
  xfail files in place -- no way we'll really pass Jacks in the near
  future)
* Build rhug
* Build Classpath
* Build kawa and pass test suite
  (I'm currently using 1.6.99, but hopefully Per will provide guidance
  on what version is best as a reference.)

Again, comments welcome.  We'll definitely need help again testing on
all the platforms.  See the old 3.1 page for a list:

    http://gcc.gnu.org/java/gcj-3.1-status.html


In the past once a release has gone out we've essentially ignored the
release branch, concentrating on the next major release.  With the 3.3
series I plan to change that and consider fixes for the minor
releases.  My current plan is to examine all patches for suitability
for the branch -- if I forget this when reviewing a patch, feel free
to remind me.

The criteria for what to put on the branch are still unknown.  Some
ideas include: "bug fix only", "binary compatible changes only", or
"upwardly binary compatible changes only" (we could add a new package
or static method, but not a new virtual method).


Soon I will set up a 3.3 status web page, like we did for 3.1.  I'll
post a note about that once it is up.

Tom