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
>
>
>
|