"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 (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.
>
+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
snapshot
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
SecurityManager
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
something
that should stand alone. jakarta-servletapi-23, and the old
jakarta-servletapi
could be changed to jakarata-servletapi-22.
> Votes please?
>
> Craig McClanahan
>
> Votes please?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
--
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
