geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <drw_...@yahoo.com>
Subject Re: How about a quick 1.1.1?
Date Wed, 24 May 2006 17:01:27 GMT
+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