Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <46E7F5BE.2070806@hanik.com>
Date: Wed, 12 Sep 2007 08:20:46 -0600
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: [VOTE] Make released versions RTC
References: <46DD1CFD.80908@gmail.com>
	 <FA97C969-28CF-44D6-BD9D-6529AADB801D@jaguNET.com>
	 <46DD822C.8060807@apache.org>
 <46DDF831.7090506@hanik.com>	 <46DE7C27.7020202@apache.org>
	 <DAE8E1AD-4CE9-426C-B26E-DD4A42FF9D8C@jaguNET.com>
	 <46DEB18A.6050403@apache.org>
 <6291fc850709050831q185c717fj83674cbe86cee47a@mail.gmail.com>
 <46E034F6.40108@apache.org> <46E03747.2060600@apache.org>
 <46E03EBC.2050500@apache.org> <46E52F49.2070300@apache.org>
 <380EC0EA-E151-47EF-9860-3317C84E7B45@jaguNET.com>
 <46E5AD7E.1090807@apache.org>
 <CAD61CFD-6F63-4844-B221-FE8CA013EA53@jaguNET.com>
 <46E7DB4A.5010304@apache.org>
In-Reply-To: <46E7DB4A.5010304@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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