Now that we've all recovered from New Years (and watched Oregon State teach
Notre Dame a few things about football -- go Beavers! :-), it's time to lay out
the next steps in Tomcat 4.0's lifetime. Here's what I propose:
(1) Tomcat 4.0 Beta 1
The code for Tomcat 4.0 has proven to be quite solid and reasonably bug free
(except for the new web connector -- see below), so it's time to start doing
beta cycles to increase the exposure and testing it receives. I would like us
to move quickly towards a "release quality" build, and therefore propose to
create Tomcat 4.0 Beta 1 on Friday 5, 2001 -- after having a chance to integrate
a few more bug fixes for issues that were reported in the last couple of weeks.
The web connector code is much less tested than the standalonie connector, so I
propose that we highlight the fact that this portion of Tomcat 4.0 is still
alpha quality. The build process has been organized so that we can create two
files (mod_webapp.so and warp.jar) and publish updates separately, if needed,
without doing a complete release. This will help us isolate and fix such
problems more quickly.
The existing "jakarta-tomcat-4.0" repository will be branched with label
"tomcat_40_branch", and each 4.0.x beta and release will receive a label such as
"tomcat_40_b1". The "main" branch of this repository will be active for bug
fixes on 4.0, while major new development will shift to the 4.1 repository
described below.
(2) Tomcat 4.1 Repository
As we approach a release quality build for Tomcat 4.0, it is also time to split
the development of major new functionality (such as the distributed session
management currently under discussion) into a development process that does not
destabilize the 4.0 release code. We can do this with a branch or a new
repository. After thinking about the relative merits of this for a bit, and
consulting with others who have managed similar evoluations, I think a new
repository is the way to go.
Therefore, I propose to create a new "jakarta-tomcat-4.1" repository on Friday
as well, based originally on the code that is marked for Tomcat 4.0 beta 1.
Because this code is just another portion of the overall code base for Tomcat,
all existing Tomcat committers will have write access to it (just as they do
with "jakarta-tomcat" and "jakarta-tomcat-4.0" today) -- no extra committer
votes are required.
NOTE: Pending this change, I would ask that we *not* commit changes to the 4.0
repository for new features that will appear in 4.1, until *after* the split.
At the same time, I will modify the build processes that create nightly
distributions of Tomcat to create a build of the most recent 4.0 tree and the
most recent 4.1 tree, so that people interested in either version can follow
along as they prefer.
(3) New "jakarta-servletapi-4.0" CVS Repository
Consistent with the suggested approach for separate Tomcat repositories for each
major version, I suggest that we also split the repository for the servlet 2.3 /
JSP 1.2 API classes. Currently, this code is in a branch (SERVET_23_JSP_12) of
the "jakarta-servletapi" repository, which makes life tougher on build scripts
than is necessary.
Therefore, I propose that we also create a new repository for these API classes
(the "4.0" part of the number matching the Tomcat major version number), with
these classes pulled out of the "jakarta-servletapi" repository -- which will
remain the current code base for servlet 2.2 / JSP 1.1.
Votes please?
Craig McClanahan
Votes please?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
