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 Thu, 13 Sep 2007 03:07:18 GMT
Mark Thomas wrote:
> Filip Hanik - Dev Lists wrote:
>   
>> 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.
>>     
>
> There doesn't have to be an incompatible API change to make something
> revolutionary. When several people have different views on how to
> implement the same feature then that meets the definition of
> revolutionary. Put each idea in a separate branch, let them evolve and
> then let the community make the decision about what to merge with trunk.
>   
ok, so there wasn't several people, and the debated feature could have 
been taken out, but the veto specifically specified to leave it in, and 
never changed.
so again, I don't/didn't see anything revolutionary in trunk,

one has yet to point to a specific feature or .java file to declare the 
revolution

Filip
>   
>>> 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.
>>     
>
> If there isn't any disagreement on the API or the implementation then
> why not put the new feature straight into 6.0.x? I don't see a problem
> with having some beta features in 6.0.x as long as they doesn't
> interfere with the existing functionality.
>
>   
>> 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.
>>     
>
> API changes - I agree. API additions I have no problem with in a dot
> release.
>
>   
>> 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
>>     
>
> Anything that starts in 6.0.x and becomes revolutionary or is
> perceived as revolutionary can be copied to a branch and reverted in
> 6.0.x. One of the nice aspects of svn is that it makes this so much
> easier and cheaper than it was was cvs.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>   


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


Mime
View raw message