tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
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?
>>     
>
> http://incubator.apache.org/learn/rules-for-revolutionaries.html
>   
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
> http://incubator.apache.org/learn/rules-for-revolutionaries.html 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

Filip

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message