Ok, it's clear that we have (currently) a different view for 2.4.
I think we should wait for 2.3.0 final and then maybe we should vote
about the roadmap and procedures for 2.4.0/3.0.
My idea on this topic could be influenced anyway by the final release
date for 2.3.0 so it does not make sense to start a long discussion on
this issue now.
Stefano
Noel J. Bergman wrote:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
