> 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.
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
ago.
- 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
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.
+1.
> (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.
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
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.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
