You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Craig R. McClanahan" <Cr...@eng.sun.com> on 2001/01/02 19:41:36 UTC
[VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
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.
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.
(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.
(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.
Votes please?
Craig McClanahan
Votes please?
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Remy Maucherat <re...@apache.org>.
> 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
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Bob Jamison wrote:
> Hi, all,
>
> Will 4.1 be read-visible in the "cvspublic" repository?
>
Ooops ... forgot a couple steps. The two new repositories ("jakarta-tomcat-4.1" and
"jakarta-servletapi-4") are now visible to anonymous CVS. Web site updates are
forthcoming.
>
> Bob Jamison
> LinCom Corp
>
Craig
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Bob Jamison <rj...@lincom-asg.com>.
Craig R. McClanahan wrote:
>
>
> (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.
>
Hi, all,
Will 4.1 be read-visible in the "cvspublic" repository?
Bob Jamison
LinCom Corp
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Marc Saegesser <ma...@apropos.com>.
This is exactly what the 4.1 repository is for. If the 4.0 and 4.1 were
going to reside in the same repository then branching would be appropriate,
but the proposal was to move all new feature development into a new
repository and there seem to be enough votes for that to happen.
> -----Original Message-----
> From: Kief Morris [mailto:kief@bitbull.com]
> Sent: Friday, January 05, 2001 9:43 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
>
>
> Marc Saegesser typed the following on 08:12 AM 1/5/2001 -0600
> >I don't see the need for branch until Tomcat 4.0 Final is relased. Until
> >then, from a source control perspective, a beta release is no
> different than
> >a milestone release. In short, what code would ever be checked
> into "main"
> >that would not also belong on the branch?
>
> I've got some code for persistent session management I would like to
> have checked in somewhere, but will need looking at, testing, and
> some extra work by more than just me before it's suitable for a beta.
> Do you think this should go into the beta? Or should I continue to work
> on it in isolation while the beta gets sorted out?
>
> A 4.1 branch or repository is clearer for me in my current situation. I'm
> currently waiting for a resolution so I can submit what I've got.
>
> Kief
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Kief Morris <ki...@bitbull.com>.
Marc Saegesser typed the following on 08:12 AM 1/5/2001 -0600
>I don't see the need for branch until Tomcat 4.0 Final is relased. Until
>then, from a source control perspective, a beta release is no different than
>a milestone release. In short, what code would ever be checked into "main"
>that would not also belong on the branch?
I've got some code for persistent session management I would like to
have checked in somewhere, but will need looking at, testing, and
some extra work by more than just me before it's suitable for a beta.
Do you think this should go into the beta? Or should I continue to work
on it in isolation while the beta gets sorted out?
A 4.1 branch or repository is clearer for me in my current situation. I'm
currently waiting for a resolution so I can submit what I've got.
Kief
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Pierre Delisle <pi...@sun.com>.
> (1) Tomcat 4.0 Beta 1
+1
> (2) Tomcat 4.1 Repository
+1
> (3) New "jakarta-servletapi-4.0" CVS Repository
+1
-- Pierre
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
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 glenn@more.net | /* Spelin donut madder |
Craig
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
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 | */ |
----------------------------------------------------------------------
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
"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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"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
> [...] 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 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
> [...]
> 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.
> [...]
+1, now when I have seen the arguments for a new repository discussed in
detail.
> (3) New "jakarta-servletapi-4.0" CVS Repository
> [...]
+1, but I would (like others) prefer just "4" (or "4.x"), or
"s22_j11" to use the spec versions instead. Another alternative
is to name it based on the JSR that defines these APIs, i.e. "jsr053".
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Marc Saegesser <ma...@apropos.com>.
> (1) Tomcat 4.0 Beta 1
-0.
I don't see the need for branch until Tomcat 4.0 Final is relased. Until
then, from a source control perspective, a beta release is no different than
a milestone release. In short, what code would ever be checked into "main"
that would not also belong on the branch?
It is completely clear to me why we need a branch once 4.0 is released. I
just don't see why we need it now.
> (2) Tomcat 4.1 Repository
+1
> (3) New "jakarta-servletapi-4.0" CVS Repository
+1
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Marc Saegesser <ma...@apropos.com>.
I think what confused me was that since this is the first release of Tomcat
4.0 there really shouldn't be anything checked into the "main" branch that
isn't also put into the beta branch. Once there is an existing product that
needs to be supported and possibly patched independent of the beta code then
I can see the need for branching.
Since 4.0 hasn't been released yet, if a nasty security bug was found during
the beta cycle we'd just fix it before releasing 4.0.
I guess I'm OK with doing a branch at this point just for consistency, but I
think we need to be very careful about any code that gets checked into
"main" (on purpose or accidentally) becuase those changes will have to be
triple-posted. Once to "main", then to tomcat_40, then to the tomcat_41
repository.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: Thursday, January 04, 2001 11:34 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
>
>
> Marc Saegesser wrote:
>
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> > >
> > > (1) Tomcat 4.0 Beta 1
> > >
> > > 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.
> >
> > I need some clarification. What will be purpose of the two branches in
> > jakarta-tomcat-4.0 (the "main" branch and tomcat_40_branch)? If we're
> > moving 4.1 development to a new repository then do we still
> need branches in
> > the jakarta-tomcat-4.0 repository?
> >
>
> The thinking is that we don't always know what the future holds.
>
> What happens if we find a really nasty security bug, right after
> 4.0 is released
> and before 4.1 is ready? The answer will be to do what we did with 3.2 --
> release a security update version (4.0.1) that fixes the security
> bug. Now,
> let's say that 4.1 takes longer than we hope - so there are some
> less urgent but
> still nice to have bug fixes we'd like to offer to 4.0 users (new
> functionality
> is generally frowned upon in a scenario like this). So maybe
> there is a 4.0.2.
> This goes on for as long as appropriate -- which, IMHO, means
> "until we are
> confident enough in 4.1 to recommend people upgrade to that."
> (And, who knows,
> there *still* might be a security fix needed nine months later
> like we did with
> 3.1.1.)
>
> The basic organizational pattern here is one I've used with great
> success on
> many projects -- keep the main branch of a particular repository
> representing
> the most recent work on the corresponding x.y version, and use
> branches to mark
> x.y.z releases.
>
> Why branches instead of labels? Because at release points we are
> creating code
> bases that have alternative future histories. A patch that fixes
> something in
> 4.0.2 might not be appropriately applied to 4.0.1 and 4.0.3, and
> the branches
> let you keep it all straight in a manner that can be clearly
> represented in
> things like GUI tools -- that is not so easy with labels because
> there isn't any
> innate relationship between labels for the tools to pick up on.
>
> Of course, in the ideal world, all of this precautionary
> organizational work is
> not needed because you've got a solid next rev to point people
> at. But, just in
> case ...
>
>
> >
> > >
> > > (3) New "jakarta-servletapi-4.0" CVS Repository
> > > 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.
> > >
> >
> > This sounds like a good plan. My only concern is that we might cause
> > confusion by naming the repository with 4.0 when this will be
> used by any
> > 4.x. Might people be looking for jakarta-servletapi-4.1, etc.?
> >
>
> They might. Alternative suggestions have been raised for
> "jakarta-servletapi-4.x" or "jakarta-servletapi-4", either of
> which I am fine
> with.
>
> Craig
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Marc Saegesser wrote:
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> >
> > (1) Tomcat 4.0 Beta 1
> >
> > 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.
>
> I need some clarification. What will be purpose of the two branches in
> jakarta-tomcat-4.0 (the "main" branch and tomcat_40_branch)? If we're
> moving 4.1 development to a new repository then do we still need branches in
> the jakarta-tomcat-4.0 repository?
>
The thinking is that we don't always know what the future holds.
What happens if we find a really nasty security bug, right after 4.0 is released
and before 4.1 is ready? The answer will be to do what we did with 3.2 --
release a security update version (4.0.1) that fixes the security bug. Now,
let's say that 4.1 takes longer than we hope - so there are some less urgent but
still nice to have bug fixes we'd like to offer to 4.0 users (new functionality
is generally frowned upon in a scenario like this). So maybe there is a 4.0.2.
This goes on for as long as appropriate -- which, IMHO, means "until we are
confident enough in 4.1 to recommend people upgrade to that." (And, who knows,
there *still* might be a security fix needed nine months later like we did with
3.1.1.)
The basic organizational pattern here is one I've used with great success on
many projects -- keep the main branch of a particular repository representing
the most recent work on the corresponding x.y version, and use branches to mark
x.y.z releases.
Why branches instead of labels? Because at release points we are creating code
bases that have alternative future histories. A patch that fixes something in
4.0.2 might not be appropriately applied to 4.0.1 and 4.0.3, and the branches
let you keep it all straight in a manner that can be clearly represented in
things like GUI tools -- that is not so easy with labels because there isn't any
innate relationship between labels for the tools to pick up on.
Of course, in the ideal world, all of this precautionary organizational work is
not needed because you've got a solid next rev to point people at. But, just in
case ...
>
> >
> > (3) New "jakarta-servletapi-4.0" CVS Repository
> > 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.
> >
>
> This sounds like a good plan. My only concern is that we might cause
> confusion by naming the repository with 4.0 when this will be used by any
> 4.x. Might people be looking for jakarta-servletapi-4.1, etc.?
>
They might. Alternative suggestions have been raised for
"jakarta-servletapi-4.x" or "jakarta-servletapi-4", either of which I am fine
with.
Craig
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Posted by Marc Saegesser <ma...@apropos.com>.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
>
> (1) Tomcat 4.0 Beta 1
>
> 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.
I need some clarification. What will be purpose of the two branches in
jakarta-tomcat-4.0 (the "main" branch and tomcat_40_branch)? If we're
moving 4.1 development to a new repository then do we still need branches in
the jakarta-tomcat-4.0 repository?
>
> (3) New "jakarta-servletapi-4.0" CVS Repository
> 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.
>
This sounds like a good plan. My only concern is that we might cause
confusion by naming the repository with 4.0 when this will be used by any
4.x. Might people be looking for jakarta-servletapi-4.1, etc.?