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] > >
