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 [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]
