RE: Release plans
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
Re: Release plans
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]
Re: Release plans
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
RE: Release plans
Norman Maurer wrote: Noel J. Bergman wrote: Stefano wrote: 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. I whould try to get the 2.3 final first and close the 2.3 branch after that. Final first, yes. But there is no need to maintain the branch after we are done with it. We run `svn cp branches/v2.3 tags/RELEASE_2_3`, which gives us a copy, then run `svn mv branches/v2.3 branches/v2.4` and we have renamed the branch. If, for some reason, we ever needed a branches/v2.3, we can copy the tag. Remember: Subversion is not CVS. We have different, better, ways to do things. Then we should copy the 2.3 to 2.4 and [decide] what we want to have in 2.4 and copy the stuff from trunk. We're differing only in SVN mechanics, as described above. 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 ? What do you mean? And why? Has anyone ever reported problems that suggest that we need fast-fail in either of those two? I don't know if those would survive the high-value test. But what about all of the admin work that Bernd has been doing? Again, my suggestion is that v2.4 be focused on the low-risk, high-value equation. This is a plan to focus development on v3, while providing a means to put only the most valuable, compatible, and lower risk improvements into a v2.4 release. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release plans
Hi, So let me add some comments.. Am Samstag, den 22.07.2006, 18:56 -0400 schrieb Noel J. Bergman: Norman Maurer wrote: Noel J. Bergman wrote: Stefano wrote: 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. I whould try to get the 2.3 final first and close the 2.3 branch after that. Final first, yes. But there is no need to maintain the branch after we are done with it. We run `svn cp branches/v2.3 tags/RELEASE_2_3`, which gives us a copy, then run `svn mv branches/v2.3 branches/v2.4` and we have renamed the branch. If, for some reason, we ever needed a branches/v2.3, we can copy the tag. Ok i think we think about the same ;-) Remember: Subversion is not CVS. We have different, better, ways to do things. Then we should copy the 2.3 to 2.4 and [decide] what we want to have in 2.4 and copy the stuff from trunk. We're differing only in SVN mechanics, as described above. See above .. 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 ? What do you mean? And why? Has anyone ever reported problems that suggest that we need fast-fail in either of those two? I don't know if those would survive the high-value test. The advance of that whould be to allow easy integration of costum handlers and fitlers.. It was just a thought which raise on a talk to Stefano.. And the benefit of that whould maybe to share technic we use for handlers.. But what about all of the admin work that Bernd has been doing? I not test it yet .. but yes the spooling commands etc could easy integrate to 2.4. Like i said with the jmx i have no expirence. But im not -1 if the others want to include it. Again, my suggestion is that v2.4 be focused on the low-risk, high-value equation. This is a plan to focus development on v3, while providing a means to put only the most valuable, compatible, and lower risk improvements into a v2.4 release. Yes.. i agree but i think a 2.4 only should released if we can put some more new code to it.. I will commit my pop before smtp stuff to trunk the next day ( maybe days) this could also be a good feature for 2.4.. But plz let us release 2.3.0 final first before get to much in details about that. I think that should be the highest prio we should focus on --- Noel bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Release plans
Am Freitag, den 21.07.2006, 00:09 +0200 schrieb Stefano Bagnara: I would like something more specific about 2.3 and generic about 2.4. I would be +1 to the following roadmap: 1) 2.3 is release candidate: we don't change anything if not to fix major/medium bugs +1 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 can backport here *anything* from trunk if we keep storage compatibility and mailet api compatibility. +1 3) 3.0 will be the next major release including any backward incompatibility issue. +1 Currently IIRC anything we have in trunk could be part of the 2.4 release as we didn't introduce any incompatibility. 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). +1 The main difference from your proposal is that I would put in every non-incompatible change in and I would try to create it from trunk instead of starting a selective merging work. Otherwise I will not be +1 because I think that we would start having too much things to vote upon about 2.4 mergin, we would start having 3 active trees (2.3, 2.4 and trunk) and too many critical issues. 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). +1 I also think that fastfail is not in final state... Furthermore the launcher stuff needs to be discussed because we may need to change our binary releases: the commons-daemon has 4 different binaries and different solutions for 4 platform (freebsd, macosx, win, linux). Tomcat does OS specific releases, we currently have a single release... we should test and include at least linux and windows and this would take much more. This is not 100% correct. Tomcat also put releases out which include the src of the jsvc . So anyone can compile it. So i see no need for diffrent binary releases... But im not against it.. About the include of the windows binaries should be tested. And see what we should do with the wrapper tools.. bye Norman Stefano Noel J. Bergman wrote: I'd like to see us get v2.3 out soon, pretty much as-is. And then, I am thinking that we might want to put out a v2.4 almost immediately thereafter, giving people choices. The differences that I would see between v2.3 and v2.4 would be incorporating the fast-fail changes and the service daemon from trunk. And once those are done, we start working on v3, with the database scheme changes as a key starting point. Are there any other relatively low risk, high benefit, easy to merge, changes between trunk and v2.3 that we might want to include in such a v2.4? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !EXCUBATOR:1,44bfff3443383522116361! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Release plans
Stefano Bagnara wrote: I would like something more specific about 2.3 and generic about 2.4. I would be +1 to the following roadmap: 1) 2.3 is release candidate: we don't change anything if not to fix major/medium bugs +1 Noel and you are right, I would really like to have jspf sooner :'( but I think it's more important to finalize 2.3.0 asap. 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 can backport here *anything* from trunk if we keep storage compatibility and mailet api compatibility. +1 3) 3.0 will be the next major release including any backward incompatibility issue. +1 Currently IIRC anything we have in trunk could be part of the 2.4 release as we didn't introduce any incompatibility. 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). The main difference from your proposal is that I would put in every non-incompatible change in and I would try to create it from trunk instead of starting a selective merging work. +1 if we are also able to keep config.xml unchanged (confining differences only to james-smtphandlerchain.xml). Otherwise I will not be +1 because I think that we would start having too much things to vote upon about 2.4 mergin, we would start having 3 active trees (2.3, 2.4 and trunk) and too many critical issues. 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). Furthermore the launcher stuff needs to be discussed because we may need to change our binary releases: the commons-daemon has 4 different binaries and different solutions for 4 platform (freebsd, macosx, win, linux). Tomcat does OS specific releases, we currently have a single release... we should test and include at least linux and windows and this would take much more. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release plans
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]
RE: Release plans
Sorry for the re-post. I found out a few minutes later (but still some hours ago) that the mail server was working its way through a 2.7 million e-mail backlog. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release plans
Noel J. Bergman wrote: I'd like to see us get v2.3 out soon, pretty much as-is. And then, I am thinking that we might want to put out a v2.4 almost immediately thereafter, giving people choices. +1 reason is simple: if we are waiting and keep waiting for bugs to be found, there will always (hopefully!) be some hot features meanwhile added to trunk - and we will never release anything because we re-start the whole cycle. The differences that I would see between v2.3 and v2.4 would be incorporating the fast-fail changes and the service daemon from trunk. And once those are done, we start working on v3, with the database scheme changes as a key starting point. +1 Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
