On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein <[EMAIL PROTECTED]> wrote: > Forgive my possible ignorance, but what is the policy on new releases? > I've understood that we can release whenever we want, that version numbers > are cheap and that you vote whether to make a release alpha/beta/GA. But, > what goes into a release? Does new features/enhancements go into a 1.2.x > release, or is it strictly bug fixes? >
What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting ("if we'd known then what we know now, what would Struts have looked like?"), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. > The reason I ask is because I would love releases much, much more often, > but as have been pointed out, incompatibilities/quirks between minor > versions could be a disaster. > Historically, I'd say our 1.0 -> 1.1 transition was, in terms of interoperability and upgrade, a bit on the edge of what most users liked, while the 1.1 -> 1.2 transition was much easier to do. We haven't actually gotten around to many x.y.z releases on 1.0 or 1.1, so having them happen at all in 1.2 should be a refreshing change :-). But I agree with you that compatibility is especially important within an x.y release cycle. > \Anders Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]