--- Ted Husted <[EMAIL PROTECTED]> wrote:We need to document the every removed method and class, at least in the release notes. Once the deprecated
AFAIK, the consensus is that our releases should follow the same general
process used by the Jakarta Commons and the Apache HTTP Server project.
So, for reference, I'm following
http://httpd.apache.org/dev/release.html
and
http://jakarta.apache.org/commons/releases/
but observing the HTTPD numbering system.
Right now, I intend to post a Release Plan for majority approval, either
late tonight or early tomorrow. This Plan would include when we plan to roll the initial Alpha release. (I may even decided just to roll a release and post that along with the Plan.) We'd then vote whether to upgrade 1.2.1 from Alpha to Beta or General Availability (GA).
Since there are any burning reasons to ship this instantly, I'm taking it as a foregone conclusion that this first roll will be at least a Beta. I'm confident that there are not any "serious problems that prohibits its use", so I don't believe it will not remain an Alpha. But,
I do suspect that there may be "problems with this release that prohibit
its widespread adoption" -- even if it simply documenting "what to do now that X is deprecated". So, I was calling it a Beta release.
We already documented this in the 1.1 @deprecated tags. I don't think we need more documentation on the deprecations.
David
methods/classes are taken out there is not a bread crumb trail to follow and it will cost use more work answering
questions on the users list than if we document it to start with. That way when they don't read the release notes
we can cut and paste the URL to the release notes.
Robert Leland [EMAIL PROTECTED] ------------------------------------------ Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201
