On 7/13/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
I agree with Wendy. Release votes should be about "here is a bunch of bits that I propose we release as version x.y.z" -- not "hey, I think the trunk is ready to go." The latter leaves open the possibility for several sorts of problems:
* Packaging problems that aren't apparent until the release
manager actually performs an "assembly" build or whatever.
* Mistakes on the part of the release manager, that lead to
building something different than what the committers thought
they were voting on.
* Differing assumptions about exactly what assembly steps
the release manager will do, versus what you (as a developer)
might expect.
I've seen enough issues like this across multiple Apache projects that I will now generally -1 any release where I'm a committer unless the proposal is for a specific set of bits someone has posted in a test repository or personal home directory for examination.
Three other points:
* Subversion tags are effectively free -- Subversion
operates on a "copy when modified" principle so
there is essentially no overhead.
* Tertiary version numbers (the "z" in " x.y.z") are
also effectively free, but it is extremely important
to never release a non-snapshot x.y.z and then
change it later. Therefore, if testing of a release
candidate finds problems, throw it away and
go build the next one.
* Doing the TCK testing on core should certainly
occur on the proposed release bits, but it is also
useful for someone to run them earlier against the
trunk build also, in an attempt to catch compatibility
issues earlier rather than later.
Craig
> Dennis, when and what are you testing? Shouldn't we tag and build it
> as 1.1.4 first?
why tagging, when the *snapshot* might be crap ?
:-)
I agree with Wendy. Release votes should be about "here is a bunch of bits that I propose we release as version x.y.z" -- not "hey, I think the trunk is ready to go." The latter leaves open the possibility for several sorts of problems:
* Packaging problems that aren't apparent until the release
manager actually performs an "assembly" build or whatever.
* Mistakes on the part of the release manager, that lead to
building something different than what the committers thought
they were voting on.
* Differing assumptions about exactly what assembly steps
the release manager will do, versus what you (as a developer)
might expect.
I've seen enough issues like this across multiple Apache projects that I will now generally -1 any release where I'm a committer unless the proposal is for a specific set of bits someone has posted in a test repository or personal home directory for examination.
Three other points:
* Subversion tags are effectively free -- Subversion
operates on a "copy when modified" principle so
there is essentially no overhead.
* Tertiary version numbers (the "z" in " x.y.z") are
also effectively free, but it is extremely important
to never release a non-snapshot x.y.z and then
change it later. Therefore, if testing of a release
candidate finds problems, throw it away and
go build the next one.
* Doing the TCK testing on core should certainly
occur on the proposed release bits, but it is also
useful for someone to run them earlier against the
trunk build also, in an attempt to catch compatibility
issues earlier rather than later.
-Matthias
Craig
> I'm making this up as I go along, referring to
> http://wiki.apache.org/myfaces/Release_Procedure as necessary. :)
>
> IMO steps 5-6-7 are out of order. We should be voting on an actual
> set of files, not a revision number in svn, and we should be testing
> exacly those files before releasing them.
>
> There's a recent thread on [EMAIL PROTECTED] about voting on tarballs vs. the
> state of the svn tree.
> http://www.mail-archive.com/[email protected]/msg06219.html
>
> Thanks,
> --
> Wendy
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
