Stefano,
> > 1) 2.3 is release candidate: we don't change anything if not to fix
> > major/medium bugs
We are agreed. So let's leave v2.3 alone, and talk about v2.4.
> 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're on the same page, right up to here:
> We can backport here *anything* from trunk if we keep storage
> compatibility and mailet api compatibility.
Yes, we CAN, but I don't know that we WANT to. I listed a few relatively
low-risk, high-value items to make the difference between v2.3 and v2.4. I
am not willing to say "*anything*" without agreeing on what each thing would
be. v2.4 should NOT be a major development, but only low-risk, high-value
additions to v2.3 while we focus on v3 (trunk).
> Currently IIRC anything we have in trunk could be part of the 2.4
> release as we didn't introduce any incompatibility.
But did we introduce any benefit? List the changes that you want to handle,
and we can talk about it. FetchMail, for example, I would say no. Why not?
Because my recollection is that there is no benefit to the new code other
than it being a bit cleaner in your view (not making a personal judgment of
my own). And, as we have all seen during the v2.3 beta phase, even the most
innocent of changes can create defects. So I maintain the v2.4 concept:
low-risk, high-value - no value, no change.
> 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).
I would not. Instead, I would rename the v2.3 branch to v2.4, after
creating the v2.3 tag. I would have no intention of maintaining v2.3.x
separately. v2.4 would be the maintanence for v2.3. And trunk would be the
next major release.
However, if someone wants to enumerate the code changes between v2.3 and
trunk, and make a case for each one, I'm willing for us all to risk assess
them. And if the final view is that using trunk for v2.4 is correct, then
that's what we'll do.
> 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).
Launcher is optional. And without the revised fast-fail, there is no reason
to have a v2.4.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
