commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject [collections] Re: Fw: Testing of a release
Date Sun, 20 Oct 2002 09:31:41 GMT
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" <mas@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
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>&nbsp;</TD>
> ---
>  >   <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A
> HREF="../../../../../index-all.html"><FONT ID="NavBarFont1"><B>Index</B><
> /FONT></A>&nbsp;</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>


Mime
View raw message