geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: How about a quick 1.1.1?
Date Wed, 24 May 2006 02:57:22 GMT

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
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.
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
optional in point releases and up to the discretion of the developer making the change.

> -dain

View raw message