geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: How about a quick 1.1.1?
Date Wed, 24 May 2006 17:37:31 GMT
There are a lot of +1s here so I went ahead and added a 1.1.1 version  
to jira.  If we decide not to do a 1.1.1, we can always delete it.

-dain

On May 24, 2006, at 10:01 AM, Donald Woods wrote:

> +1 to a 1.1.1 release, if we follow the responses/guidelines from  
> Dain and Matt below.
>
> -Donald
>
>
> Matt Hogstrom wrote:
>> Inline
>> Dain Sundstrom wrote:
>>> On May 23, 2006, at 12:53 PM, Donald Woods wrote:
>>>
>>>> I like the idea, but think we need more discussion on it -
>>>
>>>
>>> I think we need a compromise here.  If we make it too  
>>> restrictive, people won't work on "dot" releases and they will  
>>> drag out the normal release cycle to polish their bits because  
>>> they know it is there last chance.  On the other side if we let  
>>> anything in, our releases well be viewed with suspicion.  I think  
>>> the right tact to take here is to come up with some guidelines,  
>>> where stuff like schema are not changed in backwards incompatible  
>>> ways, and stuff like the web console can have larger changes.
>>>
>>> In the future, I'm hoping we can architect the server so fast  
>>> moving code, like the console, can be released at a different  
>>> schedule then say the transaction manager.  On this specific,  
>>> case a modular console would help :)
>>>
>>>> How long would we do 1.1.x releases - until 1.2 is released?
>>>
>>>
>>> I would say as long as people want to do them.  Frankly, I would  
>>> be surprised to see more that 2 of these, but if say Aaron ;) has  
>>> the energy to do more...
>>>
>>>> We would require each committer to update trunk as fixes were  
>>>> applied to 1.1.x, right?
>>>
>>>
>>> As long as the fix is still valid in trunk, absolutely.
>>>
>>>> What criteria would be used to determine what could go into a  
>>>> 1.1.x vs. what should only go into trunk?
>>>
>>>
>>> I would say 1.1.1 is limited to bug fixes and usability issues.   
>>> I would put fixing console, cli, and tooling into the usability  
>>> bucket as long a the changes don't impact he mainline server code.
>>>
>>>>   - Could prereq version updates be made in 1.1.x?
>>>
>>>
>>> I don't know what you mean.
>> If your referring to changing pre-reqs on other jars in terms of  
>> dependencies I'd say this is an it depends case.  changing pre- 
>> reqs like Tomcat Versions and the like would have a direct impact  
>> on whether a "version" was still certified or not.
>>>
>>>>   - Schema/plan changes would not be allowed in 1.1.x, right?
>>>
>>>
>>> I would allow additive optional elements, which means that any  
>>> 1.1.0 plan would work in 1.1.1+.
>>>
>> We'd need to be careful here in terms of how we end up doing  
>> clustering and Administration.  If we are expecting users to base  
>> configurations off a template this may make items incompatible.   
>> We'll also have to pay much closer attention to things that are  
>> serialized.
>>>>   - Configuration plans would be locked down (no splitting/ 
>>>> renaming contents of configs\)?
>>>
>>>
>>> Got me.
>>>
>>>>   - Would we run CTS to verify nothing has been broken?
>>>
>>>
>>> I'd say why not, but I don't think we are required.
>>>
>> I don't think this is a requirement (especially if the changes are  
>> bug fixes).  I'd say this is optional in point releases and up to  
>> the discretion of the developer making the change.
>>> -dain
>>>
>>>
>>>


Mime
View raw message