Re: The Road to 1.0

[Tom Tromey]

>>>>> "Aaron" == Aaron M Renn <address@hidden> writes:

Aaron> I think it is truly amazing how far Classpath has come in that time.
Aaron> While Paul and I haven't exactly been major contributors over the last
Aaron> year and a half, other folks have really stepped up to the plate.

If the originators can take an extended leave, and the project
continues, then you know it is successful.  Congratulations -- you've
managed to do something that is difficult and rare.

Aaron> o Get AWT working right and fix any other major holes in Java 1.1
Aaron>   support, increment the version to something like 0.9, then start
Aaron>   debugging towards 1.0

Outside of AWT, I suspect there won't be too much debugging to do.
We've actually done a substantial amount of that, since people are
already using Classpath for applications.

I took a quick look at classpath-vs-1.1 on the japi page.  We are
really shockingly close; all those green bars are delightful.  The
real question is how many of the comparison reports are there for
compliance against some later JDK.  We'd have to tweak japi to do a
3-way diff to find out, I guess.

AWT really needs a lot of love.  There are parts missing (notably
GridBagLayout -- maybe we can take Acunia's implementation though).
There are known systemic bugs (there are many places that should
acquire the tree lock that don't).  The peers aren't finished, and the
parts that are there need to be ported to the latest Gtk (you can't
even compile against Gtk 2) and are buggy besides.  The bright side is
that enough works to play around with it.

Aaron> The original thought was always that we'd target Java 1.1 as
Aaron> our 1.0 release.  However, going into real release mode would
Aaron> make it trickier to do development because of the implied
Aaron> stability contract with users.

When we get close enough, we can make a release branch with different
rules.  For instance, we can promise VM-level API stability for all
the releases in a given sequence (1.0, 1.1, 1.2, etc).

I'd rather not ever shut down the trunk.  There's no telling when
someone will implement a package.  For instance, Michael Koch has been
doing a lot of libgcj work lately.  Having a separate release branch
means we can still accept his patches at a pretty high rate; the less
certain of these can be put on the trunk only.

Tom