tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: [VOTE] Make released versions RTC
Date Tue, 04 Sep 2007 14:15:24 GMT

On Sep 4, 2007, at 4:53 AM, jean-frederic clere wrote:

> Hi,
> I would also propose that we take an handling of release branches
> similar to httpd.
> The release branches are:
> /tomcat/tc6.0.x/trunk
> /tomcat/build/tc5.5.x/
> /tomcat/container/tc5.5.x
> /tomcat/jasper/tc5.5.x/
> (Note it uses /tomcat/connectors/trunk)
> /tomcat/build/branches/tc5.0.x
> /tomcat/container/branches/tc5.0.x
> /tomcat/connectors/branches/tc5.0.x
> /tomcat/jasper/branches/tc5.0.x
> The votes will get in a file named STATUS file and once accepted in a
> file named CHANGES.
> The proposal of backports/fixes should be a description of the
> feature/PR number and a link to a commit (in another branch or  
> sandbox)
> or a patch (diff -u) against the branch.
> A proposal needs 3 +1 votes and no -1 to be accepted. The committer  
> that
> makes the proposal is responsible to commit the new code (and move the
> proposal from STATUS to CHANGES) in the branch once accepted.

I'm +1 for this type of procedure, but I don't see how
this can be shoehorned into the current setup and layout
of TC.

The basic ideas behind httpd and apr are:

   o There is a set development location (currently trunk)
     which operates under CTR.

   o There is a set release branch location which only
     operates on RTC. All code patches must first be
     applied on the development location and then be
     proposed for backport and obtain 3 (or more) +1

The premise is that there is a codebase which is CTR
and thus very free and easy, but it is never directly in
a "to be released" path. All code that is destined for
actual release must be applied to the stable/release
branch via a RTC method.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message