-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.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.- 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.-dain
smime.p7s
Description: S/MIME Cryptographic Signature
