On 11/28/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
>
> > My point is that we've already had that conversation with people, and
> > I don't want to waste precious volunteer time on discussions about why
> > Shale has Release Candidates and Action does not. We chose a strategy
> > over a year ago. AFAICT, it's working well for us.  I'd just like to
> > stay the course.
>
> I agree with you that Shale should follow the Struts convention and it
> sounds like this has been decided already.
>
> > Ah, well, it's not an "interim" release. It's a release that we have
> > graded test, Alpha, Beta, or GA.
>
> Where is this grading maintained?  In a wiki or just on the user list?
> (I'm fishing for ideas here for MyFaces as well.)
>
> > Initially, we make the build available in a committer's home directory
> > or in the usual download directory, but we do not announce it the user
> > list or submit it for mirroring until there is a quality vote. The
> > ones that make it past the test-build stage go into the archive, just
> > like most betas and rcs.
> >
> > * http://archive.apache.org/dist/struts/
> >
> > As you say, it's mainly semantics, but there are technical advantages
> > too. A huge advantage is that if we decide a build is ready for prime
> > time, we don't have to re-issue it. We just have to re-grade its
> > quality. No busy work making another release to strip off the -RC
> > designation. The HTTPD community uses a similar approach:
> >
> > * http://httpd.apache.org/dev/release.html
>
> I agree this is an advantage.  For MyFaces I was thinking that we
> might "inject" the version number into the build as part of the build
> process.  This way you can change the label of the build from RC to
> final but get the exact same SVN revision as what was tested and voted
> on.  It also saves time because you are only building one SVN branch
> for the two or three release candidates you are doing over a short
> period of time.  The SVN branches are a PITA with the SVN externals so
> that's a non trivial savings.


Getting the same thing from SVN doesn't guarantee that you'll get identical
binaries. You need to ensure that the entire environment - JDK, Maven,
plugins, env vars, etc. - remain identical as well. With the Test Build
approach, we don't need to worry about any of that.

I'm not trying to convince you to change the Struts policy.  Just
> arguing the merits of a different approach for other projects.
>
> > What I like best about the HTTPD guidelines is the idea that "an
> > impending release can not affect development of the project." One of
> > the reasons Struts Action is so far behind the times is that we've
> > allowed long beta and RC cycles to become development bottlenecks.
>
> Are you using branches for each of these releases?  We used a branch
> on the last MyFaces release and it worked well in addressing some of
> these problems.  Once we branched the impending release it was
> isolated from the nightly changes that tend to break things.


Tags, not branches. We don't create a branch until we know we need it.

--
Martin Cooper


[snip]
>
> sean
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to