tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: [VOTE] Make released versions RTC
Date Wed, 12 Sep 2007 14:20:46 GMT
Mark Thomas wrote:
>> On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
>>> The main idea is that since there's only one trunk branch, there
>>> should be agreement on APIs and important topics to proceed
>> ++1. So let's start that now. Since there is not agreement on APIs,
>> how do we proceed from here? Or, in other words, how do achieve
>> agreement on APIs?
trunk was never a revolution, there werent even API changes, except 
annotations. The comet stuff was API additions, but 100% backwards 
compatible with the old stuff.
by now we are all familiar with the rules for revolutionaries, but that 
has never been the issue around here.

> Mostly we are talking about new APIs for new features that, once
> agreed, can be added to the current version.
> It is changes to existing APIs that are more problematic. The current
> APIs will need to change occasionally (eg the Geronimo changes) and
> will need to be a new point version (6.1, 6.5 - whatever).
> We are already managing:
> - 4.1.x (mainly security and the odd bug)
> - 5.0.x (security only but needs some header work before release)
> - 5.5.x (security, bugs, some back porting of features)
> - 6.0.x (security, bugs & new features)
> Maintaining, to various degrees, 4 branches is already a fair amount
> of work for the team. I don't want to see more maintained branches
> than absolutely necessary.
> What this means is we need a set of agreed API changes for 6.0.x that
> will eventually become 6.1.x/6.5.x. I see
> as
> the way to get this agreement.
actually, preferrably it would be the other way. API changes and new 
features go into trunk, and if deemed useful,agreed upon, they get 
backported to 6.0.x.
I find it not healthy to deal with API changes on dot releases (kind of 
like the digester), especially once a branch is labeled as a stable 
release branch.
stuff like that goes into trunk, to avoid necessary delays of security 
patches and bug fixes to go out as a release.

otherwise, you'll have revolutions in 6.0.x that turn into evolutions in 6.x


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

View raw message