Michael, sorry to be formal, but does this mean the -1 is removed? If so, then we have enough votes, and the release will occur. Stephen
----- Original Message ----- From: "Michael A. Smith" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Sunday, October 20, 2002 7:46 AM Subject: Re: Fw: Testing of a release > [moving back to commons-dev since others may be interested in this] > > Henri Yandell wrote: > >>Where do we stand on the collections release? > >>Michael, at what point are you willing to remove your -1? > >>Stephen > >>(I was never meant to be a manager ... ;-) > > > > It's no different than being a librarian I reckon :) Just the books talk > > back. And being a librarian is something that any ape can do. > > I believe things look much better now. A 2.1 build using current CVS > should be fine as long as Hen's latest manifest gets included (which I > guess *is* current CVS), and xdocs/index.xml gets updated with the > latest release (see below). > > >>>The RC2 fails on - > >>>General #2 - the filename of the rc2 ends with rc1 > > > > Ack. There are times when I think that being professional at 3am is just > > stupid. That was me messing up the 'mv' command. Amazing isn't it. Fixed > > it online. > > :) > > >>>Source #4 - the xdocs source file still references 2.0 > > > > Yeah, from Daniel's RC-ing in Lang I've not been following the > > distribution stage of the build. ie) announce, make a website etc. > > I think the "latest collections release" mentioned in the xdocs source > is ok to leave as 2.0 for the release candidates, but should definately > be fixed for the actual 2.1 release build. > > >>>Source #5 - result is different, but I'm not sure why > > > > Possibly platform. Will retry. In fact will retry now before we send now > > that I've sent a nice rant to the reorg people :) > > > > .... > > > > Okay. There is a size difference it seems. Building from the zip, on the > > same machine, I get slightly smaller zip and tar.gz's than I did for the > > rc2. > > > > However, If I unzip both, do ls -l on each file, then print the file-size > > and the name of the file into a file. Then I do a diff on those two files, > > I get no differences. So that suggests that each entry of the two created > > zips [I only tested the created zips] has the same entries. > > > > I'll repeat with a cksum later on, but at first glance it seems to me that > > the difference is not due to the contents. > > I don't know how much of a difference you're seeing. For the source > distribution, a full recursive diff didn't yield any differences for me, > but I wouldn't have expected any since the source dist just pulls from > CVS. > > As for the binary distribution, I would expect there to be some > differences because the .jar file contains timestamps which probably are > different (which, due to compression, may yield different file sizes). > Additionally, the javadoc generated html files contain timestamps which > will be different, and thus possibly compress differently. But, that > would be all the differences I would expect you (Hen) to see since you > built the distribution in the first place. > > On the other hand, its possible for anyone else to see many more > differences, unless the exact same platform/JDK version is used. I > don't know what version you (Hen) used to build the binary distribution, > but I built using 1.2.2 since its the lowest version we support (this > using a class file format that should be usable by all JRE's we support). > > The binary distribution I built from the source distribution differs > greatly from the binary distribution you put out. Each class file is > different, probably because of differences in the compiler producing > slightly different bytecode (hopefully, the class file format is the > same!). > > Additionally, I see differences in the generated html like the following > (probably due to a difference in javadoc between the two versions): > > < <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A > HREF="../../../../../index-all.html"><FONT CLASS="NavBarFont1"><B>Index</ > B></FONT></A> </TD> > --- > > <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A > HREF="../../../../../index-all.html"><FONT ID="NavBarFont1"><B>Index</B>< > /FONT></A> </TD> > > [sorry for the line wrapping] > > Note the difference between CLASS="NavBarFont1" and ID="NavBarFont1" > > This difference in JDKs also manifests itself in other ways. For example: > > $ diff > /tmp/collections2.1/packaged/tar/commons-collections-2.1/META-INF/MANIFEST.M F > /tmp/collections2.1/built/tar/commons-collections-2.1/META-INF/MANIFEST.MF > 2,4d1 > < Extension-Name: org.apache.commons.collections > < Specification-Vendor: Apache Software Foundation > < Created-By: Ant 1.4.1 > 5a3 > > Created-By: Ant 1.4.1 > 6a5,6 > > Extension-Name: org.apache.commons.collections > > Specification-Vendor: Apache Software Foundation > > Again, probably due to a compiler difference whereby the manifest > entries are ordered in a different way probably based on different > environments (either differing Ant versions, or the jar tool, or > something else). > > > Speaking of which, have we specified which compiler version the binary > distributions should be built with? I would assume 1.2 since that's the > lowest version we support, thus ensuring the binary distributions are > built with the correct class file format, but 1.3 using the -target 1.2 > should work as well. This should probably be documentated in the > release procedures though. > > >>>Binary #4 - manifest contains spec version 1.0, not 2.1 > > > > Will say 2.1 in the final version. cvs commited now. > > cool. > > > Movie and popcorn time now :) Been putting wife off for long enough. > > I've somehow managed to avoid going downstairs to watch The Matrix with > my housemate... > > ... spoke too soon... can't turn down that lobby scene as they are > starting to rescue morpheus. :) > > regards, > michael > > p.s. Stephen, you may want to post your 'unit test' for a release. I > thought it was well done. Either that, or add it to the release > procedure doc as you mentioned. > > > > -- > To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org> > -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
