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
