Glenn Nielsen wrote:
> "Craig R. McClanahan" wrote:
>
> > 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?
The thinking was that we could do "maintenance-type" development in the 4.0 tree
in
between betas, and then pick and choose which bug fixes are incorporated in the
next
betas.
We can probably do all this with just labels (and no branches), but I've had
some
strange cases with CVS where it wouldn't let me go back to a previously tagged
version
*unless* it was a branch.
>
> >
> > (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?
>
I'm OK with letting Glenn finish the security manager implementation in the 4.0
release time frame. Comments?
In the mean time, I will update the STATUS documents appropriately as part of my
general cleanup of the docs.
>
> > (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.
>
Except that it's also got the JSP APIs in them as well (1.2 and 1.1,
respectively), so
the "23" and "12" identifiers are incomplete.
On my local development server, I've got the two current branches checked out
into
"jakarta-servletapi-23-12" and "jakarta-servletapi-22-11", which is a real pain,
and
does not tell you what version you need with a particular version of Tomcat.
Historical Notes -- the original release numbering plan for Tomcat (that was
approved
way back when) said that the major version number would change when the servlet
and
JSP spec levels changed. Also, the servlet API classes were originally a part
of the
Tomcat CVS repository anyway (and would thus be following along with Tomcat's
identifiers), and were split out because they are useful to people outside
Tomcat as
well.
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
