Am Sonntag, den 23.07.2006, 00:22 +0200 schrieb Stefano Bagnara: > 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. > Yes.. Let us push 2.3.0 final before make to much discusses..
I have also some stuff in queue which could be in 2.4 .. but let us talk about that later ;-) bye Norman > 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] > > !EXCUBATOR:1,44c2a56243381943058642!
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
