tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Date Wed, 03 Jan 2001 03:55:10 GMT
> Now that we've all recovered from New Years (and watched Oregon State
> 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
> (except for the new web connector -- see below), so it's time to start
> 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
> create Tomcat 4.0 Beta 1 on Friday 5, 2001 -- after having a chance to
> a few more bug fixes for issues that were reported in the last couple of

I have 4 items on my list :
- I don't like the getReporter() call. I think it should return the normal
stream, instead of creating a new one.
- Problems with setStatus() and error page generation (that's linked to the
item above).
- Enhance URL encoding according to a patch which was submitted a few days
- Stalled processors if client abruptely disconnects.

> 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
> alpha quality.  The build process has been organized so that we can create
> files ( and warp.jar) and publish updates separately, if
> 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
> 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
> the development of major new functionality (such as the distributed
> 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,
> 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
> as well, based originally on the code that is marked for Tomcat 4.0 beta
> Because this code is just another portion of the overall code base for
> all existing Tomcat committers will have write access to it (just as they
> with "jakarta-tomcat" and "jakarta-tomcat-4.0" today) -- no extra
> 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
> 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
> most recent 4.1 tree, so that people interested in either version can
> along as they prefer.

I think I like having a new repository a bit better.

> (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
> than is necessary.
> Therefore, I propose that we also create a new repository for these API
> (the "4.0" part of the number matching the Tomcat major version number),
> these classes pulled out of the "jakarta-servletapi" repository -- which
> remain the current code base for servlet 2.2 / JSP 1.1.



View raw message