So you're suggesting that I rip out the deprecated methods now, go for RC1, and damn the torpedoes that the API is incompatible between Beta 1 and RC1, and there was no warning (other than nightly builds)? You really think that's OK?
Gump builds for Tomcat and Turbine will start failing as soon as I remove the deprecated methods. Tapestry won't be affected, since Mr. Tapestry doesn't like the way Gump works, and has nailed Tapestry to Beta 1. Struts already has the necessary changes.
The question is what's best for the community. From what you say, these methods are already doomed. It's just a matter of whether they fix the dependency now or a fortnight from now. (Or just stick with whatever JAR they are already using.)
Yes, Gump may break. That's why we have Gump. =:) Sam did not create Gump to chain us, but to free us to make changes. When Gump breaks people get the heads-up that they need to make changes themselves. (Before they *voluntarily* elect to use the new version.)
And, I agree with David. We've been taking backward compatibility between betas way too seriously. In the case of Struts, our betas have languished so long that it did become prudent for us to take that into account. They became de-facto releases. But I don't agree that as a rule we have to maintain full backward compatibility between betas *and* between final releases. Otherwise, why even have betas?
When the software is released, you have established an API contract. But a beta is not a contract, it is a *proposed* contract, and subject to change until we "sign on the dotted line" and cut a final release.
Personally, I don't think anyone will be astonished that things change in an unreleased product between betas. If they are, then maybe they should step up to bat and give you a hand with what is supposed to be a community-supported product.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
