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]
