[collections] Re: Fw: Testing of a release

[Stephen Colebourne <sc...@btopenworld.com>]

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" <ma...@apache.org>
To: "Jakarta Commons Developers List" <co...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections] Re: Fw: Testing of a release

["Michael A. Smith" <ma...@apache.org>]

Stephen Colebourne wrote:
> 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

yes, my -1 is removed, and I'll now give a +1.

I still do have the concern over which JDK is used to build the binary 
distribution and whether that's an issue or not.  I wouldn't want the 
binary distribution to be unusable in 1.2.2 because it's using a new 
class file format (I also can't remember whether that changed from 1.2.2 
to 1.3 or from 1.3 to 1.4).  I'm not even sure how to confirm that.  I 
quickly tried a 1.2.2 version of javap on one of the classes compiled in 
1.4, and that seemed to work fine, so maybe I'm just crazy.  Or maybe 
jdk 1.3 and 1.4 default to using "target=1.2".  Whatever.  Not a big 
enough concern for me to hold up the release any longer.  :)

btw, thanks for putting up with me.  :)

michael

> 
> ----- Original Message -----
> From: "Michael A. Smith" <ma...@apache.org>
> To: "Jakarta Commons Developers List" <co...@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:
> 
> <ma...@jakarta.apache.org>
> 
>>For additional commands, e-mail:
> 
> <ma...@jakarta.apache.org>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>