Am Freitag, den 21.07.2006, 14:20 -0400 schrieb Noel J. Bergman: > 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. Im not 100 % sure that is the best way.. I whould try to get the 2.3 final first and "close" the 2.3 branch after that. Then we should copy the 2.3 to 2.4 and dediced what we want to have in 2.4 and copy the stuff from trunk. I think we could put and should put more then fastfail and launcher in 2.4. Maybe support fastfail also in RemoteManager and Pop3 server ?
> > 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 > bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
