Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Sender: glenn@zathras.earthdome.org
Message-ID: <3A53D535.11B83171@voyager.apg.more.net>
Date: Wed, 03 Jan 2001 19:43:17 -0600
From: Glenn Nielsen <glenn@voyager.apg.more.net>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
References: <3A5220E0.45264058@eng.sun.com>
 <3A5390F4.6AE66D8A@voyager.apg.more.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Glenn Nielsen wrote:
> 
> "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?

-0 -> +1 after reading comments

> >
> > (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?
>

-1 -> +1 But I hope we stay focused on getting 4.0 released so it doesn't just sit
         there for months like 3.2 did.
 
> > (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.
>

-1 -> +1 after reading comments about Tomcat versioning history

> > Votes please?
> >
> > Craig McClanahan
> >
> > Votes please?
> >

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