I hadn't made a point of responding since the vote was already
closed, but I've come to agree that the problems identified with the
1.3.4 build are sufficient to make it a "beta", and further, I've
just identified one or two other things that are worth nothing that
probably further justify that.
Before listing them, I'll note that I now agree that it is wrong to
call a vote on a release's quality offering the choices of "alpha,"
"beta," or "GA". Rather, we should have straight "yes/no" votes for
each of these in turn, perhaps at a prescribed interim. I would be
willing to forego always requiring an "alpha" vote, but it seems like
we should never vote a release "GA" that hasn't had a decent period
of use as a "beta" release. Some of us who have been using Struts
1.3 are confident in it, but we don't constitute a big enough
population to be the only beta testers.
I understand Don's frustration at the lack of people participating in
testing, but I think that we would get more people testing if we put
something out and called it a beta than simply expecting them to test
nightly builds and test builds. Committers should be checking test
builds and finding the kinds of packaging things that were uncovered
with Struts 1.3.3, but it takes more time to uncover other things,
and more testers.
I've uncovered a couple of things in porting an old Struts 1.1
application to 1.3; I know they probably need to go in Jira, but I
wanted to get a little discussion about them before filing them.
Actually, now I think i'll send them separately with different
subject lines to help manage the various conversations that might
arise...
Joe
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
