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]
