Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Jon Stevens wrote: > When you do a cvs co jakarta-tomcat-4.0, then you will get > a directory on your hard disk with 4.0. If you then want > to check out 4.1, you need to first reaname > jakarta-tomcat-4.0 to something else, then checkout 4.1 > on the branch, then rename it to something else, then > rename your first checkout directory back. Or you simply use the "-d" option on checkout. Example: cvs -z3 -d :pserver:rubys@localhost:/home/cvs checkout -P -r SERVLET_23_JSP_12 -d jakarta-servletapi-4.0 jakarta-servletapi - Sam Ruby P.S. I'm neutral on this. Both approaches have their advantages and disadvantages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
On 1/3/01 4:13 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > * Branches tend to be less visible to project newcomers -- > for example, anyone who checks out the main branch of > "jakarta-tomcat" today is going to wonder why it is quite > different from the 3.2.1 source distribution that he or she > grabbed off the web site. Branches cause headaches even for long term project people. There's lots of people that have been working for a very long time on Apache. They use this new repository model, and have for a while. .duncan -- James Duncan Davidson[EMAIL PROTECTED] !try; do() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
On 1/3/01 4:02 PM, "Jon Stevens" <[EMAIL PROTECTED]> wrote: > When you do a cvs co jakarta-tomcat-4.0, then you will get a directory on > your hard disk with 4.0. If you then want to check out 4.1, you need to > first reaname jakarta-tomcat-4.0 to something else, then checkout 4.1 on the > branch, then rename it to something else, then rename your first checkout > directory back. > > In other words a pain in the ass and potentially confusing for people > working on multiple versions at the same time. Yep. This has been run into in the past by other OSS projects (like FreeBSD). Having two trees is not a reinvention of the wheel -- but a solution that works pretty well as long as the main developers are all kosh with it. Another thought is to have: project-DEV project-STABLE And not use explicit subversion numbers in the cvs modulename. This would make it clear that one tree is the -DEV tree, another is the -STABLE one. I dunno, just a thought? -- James Duncan Davidson[EMAIL PROTECTED] !try; do() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
on 1/5/2001 6:51 AM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote: > Tomcat has the same problem as Struts and most Open Source > projects (it is not just an Apache thing): > * NOT ENOUGH DOCUMENTATION * Sigh, this is a lame request now. We could write documentation until we are blue in the face and that still wouldn't solve the problem (which is that as I see it is that people are not willing to put effort into learning on their own). We are not creating hugely complex molecular structures here. We are creating software based on well defined specifications. It isn't that hard to learn. VMS (the OS) had about 30 feet! of shelf space of printed documentation ( I wonder how many acres of rainforest had to be destroyed because of that operating system). That still didn't make it a better product. It still didn't make it so that people could suddenly pick up a book and know the product. > I am sorry but I can not volunteer (at the moment) to help > solving the documentation problem. With the time limitations > I have, I must find a match with my employer interests in > order to contribute with some work. (If we start having more > developers using Tomcat, maybe then it makes some sense.) Now, this is always the catch, isn't it? You have plenty of time to write a paragraph complaining about no documentation, but you don't have time to write some documentation. H No need to respond unless it is documented. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
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:[EMAIL PROTECTED]] > Sent: Friday, January 05, 2001 9:43 AM > To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Tomcat has the same problem as Struts and most Open Source projects (it is not just an Apache thing): * NOT ENOUGH DOCUMENTATION * In the case of the Jakarta projects the APIs documentation is usually quite satisfactory but the Introductions, HOW-TOs, User Guides, Architecture and other overview-level documentation are REAL CRAP! Good and well organized introductory documentation (properly marked by a big "Start Here" on the site) is the RIGHT WAY to solve that kind of problems that new Tomcat users have. Organizing code repositories in an unnatural way is the WRONG WAY to do it: - It is only going to simplify a very small part of the problems those new users face; - It is going to make developer's work harder. I am sorry but I can not volunteer (at the moment) to help solving the documentation problem. With the time limitations I have, I must find a match with my employer interests in order to contribute with some work. (If we start having more developers using Tomcat, maybe then it makes some sense.) At the time I am more focused on JSP, Struts and taglibs. Which means that I will also not volunteer for that mod_rewrite-like functionality that Jon asked for... but maybe we will contribute some taglibs in the near future. (Still must talk with the boss on that.) Have fun, Paulo Gaspar > -Original Message- > From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 05, 2001 11:17 > > >I don't see any problem - there are 2 codebases - the > >"original" tomcat ( > >3.x ) and catalina ( 4.x ). > > You're in the project but imagine when a new user arrive and > want to use a servlet engine ;-) The question will be must > I use 3.2, 3.3, 4.0 or 4.1 ?-) > > A simple help rule could be : > > - If you have JDK 1.1 and Servlet 2.2/JSP 1.1, use 3.2/3.3 > - If you could use JDK 1.2 and need Servlet 2.3/JSP 1.1, use 4.0/4.1 > > May be nice to add on tomcat site ... > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
> (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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
>I don't see any problem - there are 2 codebases - the >"original" tomcat ( >3.x ) and catalina ( 4.x ). You're in the project but imagine when a new user arrive and want to use a servlet engine ;-) The question will be must I use 3.2, 3.3, 4.0 or 4.1 ?-) A simple help rule could be : - If you have JDK 1.1 and Servlet 2.2/JSP 1.1, use 3.2/3.3 - If you could use JDK 1.2 and need Servlet 2.3/JSP 1.1, use 4.0/4.1 May be nice to add on tomcat site ... >For 3.x, the stable version is 3.2, the development version is 3.3. >( we also have 3.0 and 3.1 - the previous "stable" versions - still in >use, including 3.0 ) >For 4.x, the stable version will be 4.0, the development version 4.1. > +1 >For 3.x I would like that we keep it as it is, with branches/tags for >releases and the development going on in the main tree. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
"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 [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
> >so +1 , but i continue to not see any advantages in maintain another > >repository.. > > > > Like Nacho I turn my -1 to +1 since I don't want the TC 4.x development > to be stopped or features freezed but I feel that It will became > hard to find our way in 3.2, 3.3, 4.0 and 4.1 I don't see any problem - there are 2 codebases - the "original" tomcat ( 3.x ) and catalina ( 4.x ). For 3.x, the stable version is 3.2, the development version is 3.3. ( we also have 3.0 and 3.1 - the previous "stable" versions - still in use, including 3.0 ) For 4.x, the stable version will be 4.0, the development version 4.1. For 3.x I would like that we keep it as it is, with branches/tags for releases and the development going on in the main tree. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
>so +1 , but i continue to not see any advantages in maintain another >repository.. > Like Nacho I turn my -1 to +1 since I don't want the TC 4.x development to be stopped or features freezed but I feel that It will became hard to find our way in 3.2, 3.3, 4.0 and 4.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
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:[EMAIL PROTECTED]] > Sent: Thursday, January 04, 2001 11:34 AM > To: [EMAIL PROTECTED] > Subject: Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories > > > Marc Saegesser wrote: > > > > -Original Message- > > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > > > > > (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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Marc Saegesser wrote: > > -Original Message- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > > > (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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
> -Original Message- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > (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.? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
GOMEZ Henri wrote: > > -1 - We'll have now 3.2, 3.3, 4.0 and 4.1 branches > Too many branches for the same project. > Please don't reopen a 3.x against 4.x campaign. Henri, I would like to ask you to voluntarily remove your -1. The only way to make progress towards a 4.0 release is to slow down the rate of potentially disruptive change for a brief period. In an all volunteer organization (and often in commercial development too), the only way to make that work is to provide an alternate place for other changes to be made. The way I did that in the past was to cut a branch for the release I was trying to shut down and get out the door. The current preferred approach is to create a new cvs module. They both accomplish essentially the same thing. (I'm neutral on this - I miss the access to the long term change history, but I do see compensating advantages). Without an effective means to get a release out the door, what your veto essentially would argue that the existence of a 3.x baseline would preclude the ability to ever have a 4.0 release in any form, and certainly that wouldn't be in the best interests of anybody, right? - Sam Ruby P.S. Craig, Jon, and other PMC members lets discuss the meaning of vetos in the upcoming F2F. I am growing increasingly displeased with the apparent attitude that "since I disagree with your reason for a veto, it is not valid, and therefore it can be ignored". - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
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? > > ---
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Dan Milstein wrote:
> >
> > On the other hand, a separate repository causes no problems that I've
> > experienced, and avoids all of the issues listed above.
>
> I agree that branches under CVS are way, way confusing, and so I'll support a
>separate repository. The one disadvantage I do see, however, is that we'll lose the
>ability for CVS to automatically merge changes from one branch into the other. For
>example, if we have a 4.0 and a 4.1 ("Head") branch, then, *in theory*, we could make
>bugfixes on 4.0, and then ask CVS to automatically merge those fixes into the "main"
>4.1 branch.
>
> With separate repositories, we'll have to do those merges by hand.
>
Point well taken.
I'm not at all a fan of automated merges ... CVS gives me enough grief already merging
conflicts on individual files :-)
>
> On the other hand, having worked extensively with CVS branches, those merges between
>branches are very temperamental, so I want to emphasize the "in theory" part.
>
Yep. It is one of those "sounds wonderful" things, but I cringe every time I run one.
Also, my historical experience has been that the need for branch merging *between* dot
releases (4.0 and 4.1 in this scenario) is quite a lot less common than merging code
branches *within* a dot release.
But the option to do this automatically is something we give up.
>
> Just I thought I should point this out...
>
> -Dan
>
Craig
>
> >
> > * Branches are mysterious to CVS newbies, and make
> > the learning process that much harder than it needs to be.
> > It's also messier for folks (like me) who have to work on
> > multiple releases at the same time.
> >
> > * Branches tend to be less visible to project newcomers --
> > for example, anyone who checks out the main branch of
> > "jakarta-tomcat" today is going to wonder why it is quite
> > different from the 3.2.1 source distribution that he or she
> > grabbed off the web site.
> >
> > * Branches make life harder for "automated check out and build"
> > scripts like the one I use to create nightly distros of several of
> > the Jakarta packages, and like what Sam Ruby is building at:
> >
> > http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/index.html
> >
> > You have to make special provisions in scripts like this to check
> > out branches other than the main one, which makes them more
> > fragile and error-prone.
> --
>
> Dan Milstein // [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
>
> On the other hand, a separate repository causes no problems that I've
> experienced, and avoids all of the issues listed above.
I agree that branches under CVS are way, way confusing, and so I'll support a separate
repository. The one disadvantage I do see, however, is that we'll lose the ability
for CVS to automatically merge changes from one branch into the other. For example,
if we have a 4.0 and a 4.1 ("Head") branch, then, *in theory*, we could make bugfixes
on 4.0, and then ask CVS to automatically merge those fixes into the "main" 4.1 branch.
With separate repositories, we'll have to do those merges by hand.
On the other hand, having worked extensively with CVS branches, those merges between
branches are very temperamental, so I want to emphasize the "in theory" part.
Just I thought I should point this out...
-Dan
>
> * Branches are mysterious to CVS newbies, and make
> the learning process that much harder than it needs to be.
> It's also messier for folks (like me) who have to work on
> multiple releases at the same time.
>
> * Branches tend to be less visible to project newcomers --
> for example, anyone who checks out the main branch of
> "jakarta-tomcat" today is going to wonder why it is quite
> different from the 3.2.1 source distribution that he or she
> grabbed off the web site.
>
> * Branches make life harder for "automated check out and build"
> scripts like the one I use to create nightly distros of several of
> the Jakarta packages, and like what Sam Ruby is building at:
>
> http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/index.html
>
> You have to make special provisions in scripts like this to check
> out branches other than the main one, which makes them more
> fragile and error-prone.
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Hola Jon: > The problem is that say you are working on 4.0 and 4.1 at the > same time. > I do this with branches ( cocoon2 , 3.2 , 3.X ) all the time, only by using another directory.. > When you do a cvs co jakarta-tomcat-4.0, then you will get a > directory on > your hard disk with 4.0. If you then want to check out 4.1, > you need to > first reaname jakarta-tomcat-4.0 to something else, then > checkout 4.1 on the > branch, then rename it to something else, then rename your > first checkout > directory back. > The problem is another ( at least for me and the resaon i changed my vote ), the problem is that i need to checkout another projects in the same branch_dir make it work as the build scripts are tied to a common root above, so if i checkout branch tomcat_32 to a dir, then i need to checkout jakarta-servletapi, and jakarta_ant to the same dir to use the standard build.bat work, the way you propose this is not necessary and i can have all the branches at same level without need to do double checkouts ( in the main directory and inside the branch dir ).. Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Nacho wrote: > > (1) Tomcat 4.0 Beta 1 > > > > +1 > > > > > (2) Tomcat 4.1 Repository > > > > > > -1 > > Please explain what are the problem with branches, i dont see why label > a branch with tomcat_40 and do 4.1 development in head branch is bad, i > dont see any desestabilization or such in this way of doing things, i > want to know why is better to do things in such way, as dont see it very > explained in the messages of this thread. > Here are at least a few areas I've seen problems when using branches versus separate repositories: * Branches are mysterious to CVS newbies, and make the learning process that much harder than it needs to be. It's also messier for folks (like me) who have to work on multiple releases at the same time. * Branches tend to be less visible to project newcomers -- for example, anyone who checks out the main branch of "jakarta-tomcat" today is going to wonder why it is quite different from the 3.2.1 source distribution that he or she grabbed off the web site. * Branches make life harder for "automated check out and build" scripts like the one I use to create nightly distros of several of the Jakarta packages, and like what Sam Ruby is building at: http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/index.html You have to make special provisions in scripts like this to check out branches other than the main one, which makes them more fragile and error-prone. On the other hand, a separate repository causes no problems that I've experienced, and avoids all of the issues listed above. > > > > > (3) New "jakarta-servletapi-4.0" CVS Repository > > > > +1 perhaps it's more clean "jakarta-servletapi-4.X" > But didn't you just argue for *not* splitting the jakarta-tomcat-4.0 repository? :-) I'm fine with a suffix of "4.X" (or maybe just "4"), since the spec revs won't change through the life of Tomcat 4.x. > > Saludos , > Ignacio J. Ortega > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Hola a TOdos: > > (2) Tomcat 4.1 Repository > > > > > I've changed my opinion, it's the same so +1 , but i continue to not see any advantages in maintain another repository.. Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
on 1/3/2001 3:55 PM, "Nacho" <[EMAIL PROTECTED]> wrote: > Please explain what are the problem with branches, i dont see why label > a branch with tomcat_40 and do 4.1 development in head branch is bad, i > dont see any desestabilization or such in this way of doing things, i > want to know why is better to do things in such way, as dont see it very > explained in the messages of this thread. The problem is that say you are working on 4.0 and 4.1 at the same time. When you do a cvs co jakarta-tomcat-4.0, then you will get a directory on your hard disk with 4.0. If you then want to check out 4.1, you need to first reaname jakarta-tomcat-4.0 to something else, then checkout 4.1 on the branch, then rename it to something else, then rename your first checkout directory back. In other words a pain in the ass and potentially confusing for people working on multiple versions at the same time. -jon -- Honk if you love peace and quiet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
> (1) Tomcat 4.0 Beta 1 > +1 > > (2) Tomcat 4.1 Repository > > -1 Please explain what are the problem with branches, i dont see why label a branch with tomcat_40 and do 4.1 development in head branch is bad, i dont see any desestabilization or such in this way of doing things, i want to know why is better to do things in such way, as dont see it very explained in the messages of this thread. > > (3) New "jakarta-servletapi-4.0" CVS Repository > +1 perhaps it's more clean "jakarta-servletapi-4.X" Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
on 1/3/2001 1:48 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > NOTE: There will be a short period of time where "double posting" of bug fix > patches will be required (which will end when we stop doing 4.0.x maintenance > releases because 4.1.x is stable). The developer effort to do this is > identical > for a branch or for a separate repository. > > Bottom Line -- it does not appear to me that "too many branches" (without a > suggested alternative) is a valid > reason for a veto. If you have an alternative suggestion for how we should > organize 4.x ongoing release management, I'm all ears. > > Craig McClanahan +1. Either suggest an alternative or remove your -1. -jon -- Honk if you love peace and quiet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
GOMEZ Henri wrote: > > >(2) Tomcat 4.1 Repository > > -1 - We'll have now 3.2, 3.3, 4.0 and 4.1 branches > Too many branches for the same project. > Please don't reopen a 3.x against 4.x campaign. > I'm not ... nothing in the proposal says anything at all about anything labelled "Tomcat 3.x". The only purpose is to identify an ongiong development process for 4.x as we move fowards, and follows standard release management practices. What we need to do, along with a feature freeze on 4.0 in order to enter beta, is to not stifle further 4.x development (such as whatever comes of the current discussions about distributed session management support).In order to avoid destabilizing a 4.0 release, we clearly do not want to do changes on such a fundamental feature during beta. So, we're going to need to temporarily have two parallel development streams in 4.x. Given that we're using CVS, there are two basic choices -- a branch in the "jakarta-tomcat-4.0" repository, or a separate repository. Having seen the problems that branches can cause, and seeing what other projects (like the Apache web server itself) do, it makes more sense to me to do the latter. NOTE: There will be a short period of time where "double posting" of bug fix patches will be required (which will end when we stop doing 4.0.x maintenance releases because 4.1.x is stable). The developer effort to do this is identical for a branch or for a separate repository. Bottom Line -- it does not appear to me that "too many branches" (without a suggested alternative) is a valid reason for a veto. If you have an alternative suggestion for how we should organize 4.x ongoing release management, I'm all ears. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
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
RE: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
>(1) Tomcat 4.0 Beta 1 +1 - Need to enter Beta process >(2) Tomcat 4.1 Repository -1 - We'll have now 3.2, 3.3, 4.0 and 4.1 branches Too many branches for the same project. Please don't reopen a 3.x against 4.x campaign. >(3) New "jakarta-servletapi-4.0" CVS Repository +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
"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 | */ | -
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
> (1) Tomcat 4.0 Beta 1 +1 > (2) Tomcat 4.1 Repository +1 > (3) New "jakarta-servletapi-4.0" CVS Repository +1 -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [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. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
