You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Craig McClanahan <cr...@apache.org> on 2006/07/12 19:47:11 UTC
Testing for CoreRelease114
I temporarily modified the Shale build environment to use 1.1.4 instead of
1.1.1, and was able to successfully build and run all the unit tests and
integration tests (meaning I could deploy apps and run through some basic
exercises on some of the standard components).
One thing I would note in the release notes is that the Maven group
identifier is changing (myfaces->org.apache.myfaces.core) as well as the
version number.
Craig
Re: Testing for CoreRelease114
Posted by Matthias Wessendorf <ma...@apache.org>.
ok!
On 7/13/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
>
> On 7/13/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > 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 dev@tomcat about voting on tarballs vs. the
> > > state of the svn tree.
> > >
> http://www.mail-archive.com/dev@tomcat.apache.org/msg06219.html
> > >
> > > Thanks,
> > > --
> > > Wendy
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Testing for CoreRelease114
Posted by Craig McClanahan <cr...@apache.org>.
On 7/13/06, Matthias Wessendorf <ma...@apache.org> wrote:
>
> > 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 dev@tomcat about voting on tarballs vs. the
> > state of the svn tree.
> > http://www.mail-archive.com/dev@tomcat.apache.org/msg06219.html
> >
> > Thanks,
> > --
> > Wendy
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: Testing for CoreRelease114
Posted by Wendy Smoak <ws...@gmail.com>.
On 7/13/06, Matthias Wessendorf <ma...@apache.org> wrote:
> Wendy wrote:
> > 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 ?
The more testing, the better! Is someone is going to run the TCK
again on the final 1.1.4 jars?
The Release Procedure wiki page only has a general comment about
running it once... what's the usual procedure?
--
Wendy
Re: Testing for CoreRelease114
Posted by Matthias Wessendorf <ma...@apache.org>.
> 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 ?
:-)
-Matthias
> 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 dev@tomcat about voting on tarballs vs. the
> state of the svn tree.
> http://www.mail-archive.com/dev@tomcat.apache.org/msg06219.html
>
> Thanks,
> --
> Wendy
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Testing for CoreRelease114
Posted by Wendy Smoak <ws...@gmail.com>.
On 7/13/06, Matthias Wessendorf <ma...@apache.org> wrote:
> Dennis will test MyFaces-Core 1.1.4 against the TCK.
Dennis, when and what are you testing? Shouldn't we tag and build it
as 1.1.4 first?
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 dev@tomcat about voting on tarballs vs. the
state of the svn tree.
http://www.mail-archive.com/dev@tomcat.apache.org/msg06219.html
Thanks,
--
Wendy
Re: Testing for CoreRelease114
Posted by Matthias Wessendorf <ma...@apache.org>.
Dennis will test MyFaces-Core 1.1.4 against the TCK.
-Matthias
On 7/12/06, Matthias Wessendorf <ma...@apache.org> wrote:
> Thanks Craig,
>
> did the same just for the Trinidad Podling. Worked too :)
> the maven group id is since 1.1.2.
>
> -Matthias
>
> On 7/12/06, Craig McClanahan <cr...@apache.org> wrote:
> > I temporarily modified the Shale build environment to use 1.1.4 instead of
> > 1.1.1, and was able to successfully build and run all the unit tests and
> > integration tests (meaning I could deploy apps and run through some basic
> > exercises on some of the standard components).
> >
> > One thing I would note in the release notes is that the Maven group
> > identifier is changing (myfaces->org.apache.myfaces.core) as well as the
> > version number.
> >
> > Craig
> >
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Testing for CoreRelease114
Posted by Matthias Wessendorf <ma...@apache.org>.
Thanks Craig,
did the same just for the Trinidad Podling. Worked too :)
the maven group id is since 1.1.2.
-Matthias
On 7/12/06, Craig McClanahan <cr...@apache.org> wrote:
> I temporarily modified the Shale build environment to use 1.1.4 instead of
> 1.1.1, and was able to successfully build and run all the unit tests and
> integration tests (meaning I could deploy apps and run through some basic
> exercises on some of the standard components).
>
> One thing I would note in the release notes is that the Maven group
> identifier is changing (myfaces->org.apache.myfaces.core) as well as the
> version number.
>
> Craig
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com