tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Date Wed, 03 Jan 2001 20:52:04 GMT
"Craig R. McClanahan" wrote:
> 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 ( 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.

+1 for separate mod_wepp/warp releases.

> 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.

-0 I'm not sure what the above branches buy us, will all bug fixes and commits
   still go to the main 4.0 branch?  With the other beta branches just being a
   of the code when the beta was released?
> (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.

-1 I would rather see a feature freeze for 4.0, and continue to focus efforts
   on completing, testing, and bug fixing 4.0.  (I want to have the Java
   as a 4.0 feature)  Once 4.0 is released then fork the code.  This way we will
   stay focused on the 4.0 release.  Could an updated list of features and their
   status be posted?
> (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.

-1 I would rather not see the servletapi tied to a Tomcat version, it is
   that should stand alone.  jakarta-servletapi-23, and the old
   could be changed to jakarata-servletapi-22.

> Votes please?
> Craig McClanahan
> Votes please?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

Glenn Nielsen    | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |

View raw message