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]
