Ted said (I just love that aliteration...): > My suggestion would be to schedule a Beta 4 against the > nightly build, > and then to not hesitate releasing B4 as Struts 1.1. final if > it flies. > The idea being we suspect that B4 is a "defacto" release > candidate, and > may go from B4 to Release, if appropriate.
The only different is that if we call it an RC, people who have been sitting on the fence waiting to adopt might actually try 1.1 and we can flush out any hidden bugs that are only uncovered by strenuous applications testing. > > One thing I would discourage would be cutting a Release > Candidate if we > "strongly suspect" that we will need another RC. I strongly suspect only because I trust in comrade Murphy, and that there's Always One More Bug. > > One definition of Release Candidate is > > o "Release candidate" means we think this build is it, and will only > change high priority bugs -- and API changes are totally verbotten. I think that's where we are, aren't we? I wouldn't be shocked if an RC based on a currently nightly build couldn't become the final. Declaring it a release candidate is more a signal than anything, it says: "The didling is done, we intend to release the final product very shortly, this might be it, start using it so you'll be ready." James -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
