I would like something more specific about 2.3 and generic about 2.4.
I would be +1 to the following roadmap:
1) 2.3 is release candidate: we don't change anything if not to fix
major/medium bugs
2) 2.4 is the next 2.x release (we had this in roadmap until you decided
at apachecon to keep only 3.0 ;-) ) and is storage compatible with 2.2
(like 2.3). We can backport here *anything* from trunk if we keep
storage compatibility and mailet api compatibility.
3) 3.0 will be the next major release including any backward
incompatibility issue.
Currently IIRC anything we have in trunk could be part of the 2.4
release as we didn't introduce any incompatibility.
If we want to follow this roadmap I would avoid to commit anything 3.0
specific in trunk until we have a 2.3.0 final out. Then I would start a
2.4.0 branch from the trunk of that moment and from that point we would
still have 2 active tree (2.4 branch and trunk for 3.0).
The main difference from your proposal is that I would put in every
non-incompatible change in and I would try to create it from trunk
instead of starting a selective merging work.
Otherwise I will not be +1 because I think that we would start having
too much things to vote upon about 2.4 mergin, we would start having 3
active trees (2.3, 2.4 and trunk) and too many critical issues.
About your specific proposal (having a 2.4 as a 2.3+fast fail+launcher)
I'm currently -1 because I think fast fail need much more work and the
launcher is to be tested and there is much more that deserve inclusion
in a 2.4 release before (almost all we currently have in trunk).
Furthermore the launcher stuff needs to be discussed because we may need
to change our binary releases: the commons-daemon has 4 different
binaries and different solutions for 4 platform (freebsd, macosx, win,
linux). Tomcat does OS specific releases, we currently have a single
release... we should test and include at least linux and windows and
this would take much more.
Stefano
Noel J. Bergman wrote:
I'd like to see us get v2.3 out soon, pretty much as-is. And then, I am
thinking that we might want to put out a v2.4 almost immediately thereafter,
giving people choices.
The differences that I would see between v2.3 and v2.4 would be
incorporating the fast-fail changes and the service daemon from trunk. And
once those are done, we start working on v3, with the database scheme
changes as a key starting point.
Are there any other relatively low risk, high benefit, easy to merge,
changes between trunk and v2.3 that we might want to include in such a v2.4?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
