> 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. 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. [snip] sean --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
