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]
