On 11/28/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > People may wonder what happened > to the "interim" release numbers.
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. > > A few questions. For these interim builds that don't get released > officially. I assume these builds aren't in the apache archive or > Maven repository right? You just make them in the nightly dir or > something for people to evaluate? Also, for bug reporting do you > recommend a verison number for each interim release? Ah, well, it's not an "interim" release. It's a release that we have graded test, Alpha, Beta, or GA. 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 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. It would be particularly useful for our Commons components to use the "milestone-only" scheme, since something like the Commons-Validator could start out as a "beta" and then based on its success in a beta Struts distribution be upgraded to GA. When that happened, we would not have to create another Struts release t. We might be able to upgrade the relesae we already had, without changing the list of dependencies. > > sean --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
