james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject RE: Release plans
Date Sat, 22 Jul 2006 08:49:45 GMT
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

View raw message