David H. DeWolf wrote:
The idea is that you cut the "test build" and
then vote on it's quality. We can publish on the website whether a
particular build is alpha, beta, or ga, but it's not part of the actual
build name. This approach is consistent with not only struts, but many
other apache projects (tomcat, tiles, http, etc. . .).
The biggest advantage is that IMHO the release process becomes easier to
manage. Instead of having to wait around for everything to be perfect
if we're trying to cut a GA release, we can cut the test build and vote
on the quality after the fact. If it fails, we remove it and move on.
If it's good, but not great, we can call it a beta and move on. In
short, if we take this approach, I would hope that we get more frequent
releases.
This sounds like a practical, common sense approach.
For example, 1.1.1 is not a drastic code refactor and the changes going
into 1.1.1 (both the number of changes and the scope of the changes are
"small") probably won't result in a "beta" or "alpha" designation. So
we can vote and ship 1.1.1 GA relatively quickly.
On the other hand, when 286 is merged into trunk and we are ready to
make a release, it may be that based on test results, a "beta"
designation is appropriate and useful to the community.
My original concern when I proposed dropping alpha and beta from
releases was expediency. I would prefer to not have to go through
posting a build designated "beta" if we feel it is GA quality.
Elliot
