On Mon, 2006-02-27 at 17:54 +0100, Mark Wielaard wrote: > Hi all, > > As some people have been saying already there were some impressive > showcases at Fosdem of things that just work now. So I feel it is time > to do a new snapshot this week to share all this great work with our > users. Both awt and swing made some very nice improvements, we have all > the new crypto algorithms now (https support out of the box), new > rmi/corba tools, unicode 4.0 support, (VM)Math improvements, regex > improvements, and probably lots of other things I am forgetting now. > (Please update the NEWS file!) > > It looks like we are in pretty good shape. Some smoke-tests with some > simple applications work nicely for me. And Mauve gives us this > impressive score: > classpath-0.20 38115 PASS 983 FAIL > classpath-0.21-pre 43615 PASS 583 FAIL > There are some regressions that builder didn't seem to have picked up > though (attached). We need to go through these to see whether they are > fatal/embarrassing. > > Other things to do: > - Update the NEWS file! > - Test more apps. > - Go through the bug-list for "must fix" things. > - Remerge CVS trunk with the generics branch > (I don't know whether Andrew has had time for that since his Math > work. Please yell and scream if you need help with this Andrew.) It's mostly there. I expected to have it in during the weekend, but the merge included a few classes that differ significantly between the branches and had to be merged manually (e.g. the Character changes, changes to the collection classes). Hopefully, I should be able to wrap it up sometime tomorrow morning (GMT). This will bring it in sync up to about the 25th (Saturday). It then just needs to be brought up to date with the patches inbetween Saturday and the point where the release is called. The Math changes make this particularly important as otherwise generics will ship with broken floating point stuff... :( I can do this too, but if anyone wants to help out, I'd be grateful. More specifically, if you did a recent patch and have a checked-out and compiling generics branch too, it would be great if you could commit to that as well once the initial merge is over. The majority of stuff _should be_ fairly clean to apply (java.util stuff is usually the exception). Post-release, I'd like to do a run-through in the opposite direction, checking that everything in generics branch that should be in HEAD is... This has already caused a few hiccups in the past. My take on that is that anything that will compile there should be on HEAD, but I'd be interested to hear what others think. It depends on whether you want to target the generics branch for people who need to do stuff with generics, enums, etc. or just generally for people who want some level of 1.5 compatability. > - Make builder produce a real classpath-generics dist again. > (I'll try to take a look at that tonight.) Would be great to see that. > - Decide on the version number. > We had a very small/brief discussion about this during Fosdem. > Everybody seems to agree 0.x really doesn't do justice to the maturity > we have reached over the years. And it is really hard to define when > we hit "1.0". So the proposal is to keep using a "sequence version > number". Either just drop the "0." and make the next release-number > classpath-21, or adopt a year.month style version number and make the > next version number classpath-6.3 for the March 2006 release. > In either case we will just use a code name for a release that has > some special feature set that we are proud of, but we will always > just increase the release snapshot number. Suggestions or Opinions? > Jumping version numbers would be very appropriate for a Java library release... ;) Either of the 0.9-->1 or 1.4.x, 1.5.x suggestions sounds good to me. The latter sound better for a final versioning system, but I'm wary of calling us 1.4 yet. API compatability isn't everything. Although, on that note, it would be nice to have HEAD as 1.4.x and the generics branch as 1.5.x (one being our current 'stable' release, the other being the next big thing eventually). > Different from previous releases I will probably create a branch for > this one. If things look basically OK, I'll create that on Wednesday and > then test that and back-port patches from CVS trunk to it till it is > "perfect". That makes sure other people can just happily go on hacking. > Please let me know if there is something you feel would be really nice > to have in for this release. > Sounds like a good idea, especially as CVS is so much more active these days (in that I can't get a patch in in the space it takes me to write the Changelog). A release branch would also mean we could apply bad regressions to it if we find any later on. Classpath is different from most other codebases in that we don't really have features in new releases, and fixes to the old ones; everything at present is an attempt to get a certain level of functionality that exists elsewhere. However, the stuff with the Math classes this weekend reminds that we really could do with a means to provide release fixes where there are major breakages on the initial version that weren't caught initially. I recall at least one Classpath release that had this problem. This is especially true if we want to move away from snapshot releases to a versioning system with more of a 'stable' feel. > Cheers, > > Mark ... -- Andrew :-) Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments. See http://www.fsf.org/philosophy/no-word-attachments.html If you use Microsoft Office, support movement towards the end of vendor lock-in: http://opendocumentfellowship.org/petition/ "Value your freedom, or you will lose it, teaches history. `Don't bother us with politics' respond those who don't want to learn." -- Richard Stallman Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html public class gcj extends Freedom implements Java { ... } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://developer.classpath.org/pipermail/classpath/attachments/20060227/54a55664/attachment.pgp
