Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Le 09/05/2024 à 13:21, Jacques Le Roux a écrit : Hi Michael, Inline again Le 08/05/2024 à 21:00, Jacques Le Roux a écrit : 3. suddenly there was a mass of new PR's which were merged in a hurry unneccesarily (my personal point of view), with some corrections soon after 4. 3. blocks 1. even further now because those changes are not complete/not rolled out for every component. I'm unsure that these changes are not complete for every component and even if it's the case it should not block the creation of a release branch. And if ever issues remain (not necessarily related to these changes) it's not a big deal to fix them once freezed. Instead of 3. we should have delayed merging those new features and worked on the blocking issues of 2. to be able to create a release from an almost stable trunk. So you speak about other known issues than https://issues.apache.org/jira/browse/OFBIZ-12995. Have you a clear view about them ? Else my answer to 4. should be reassure you, not a big deal. To complete, I guess you speak about https://issues.apache.org/jira/browse/OFBIZ-12928. A large majority is completely done and resolved when needed (thanks to trunk demo logs) Only 3 (on 46) are pending: https://issues.apache.org/jira/browse/OFBIZ-12951. I let a bit of time to Pierre. If it's still pending when we want to Freeze we should revert. https://issues.apache.org/jira/browse/OFBIZ-12978. Nothing done there yet. https://issues.apache.org/jira/browse/OFBIZ-13042. Waiting for a fix before pushing. As ever with Pierre, we disagree about https://issues.apache.org/jira/browse/OFBIZ-13068. As I said there, and knowing how it gets in such cases, I prefer to "keep this issue reopened and I'll not close your PR." I have created https://cwiki.apache.org/confluence/display/OFBIZ/Release+24.xx+Roadmap Unrelated : I also plan to close a lot of old pending Jira soon... Jacques There is also https://issues.apache.org/jira/browse/OFBIZ-13049. But that's out of scope for the moment.
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Michael, Inline again Le 08/05/2024 à 21:00, Jacques Le Roux a écrit : 3. suddenly there was a mass of new PR's which were merged in a hurry unneccesarily (my personal point of view), with some corrections soon after 4. 3. blocks 1. even further now because those changes are not complete/not rolled out for every component. I'm unsure that these changes are not complete for every component and even if it's the case it should not block the creation of a release branch. And if ever issues remain (not necessarily related to these changes) it's not a big deal to fix them once freezed. Instead of 3. we should have delayed merging those new features and worked on the blocking issues of 2. to be able to create a release from an almost stable trunk. So you speak about other known issues than https://issues.apache.org/jira/browse/OFBIZ-12995. Have you a clear view about them ? Else my answer to 4. should be reassure you, not a big deal. To complete, I guess you speak about https://issues.apache.org/jira/browse/OFBIZ-12928. A large majority is completely done and resolved when needed (thanks to trunk demo logs) Only 3 (on 46) are pending: https://issues.apache.org/jira/browse/OFBIZ-12951. I let a bit of time to Pierre. If it's still pending when we want to Freeze we should revert. https://issues.apache.org/jira/browse/OFBIZ-12978. Nothing done there yet. https://issues.apache.org/jira/browse/OFBIZ-13042. Waiting for a fix before pushing. As ever with Pierre, we disagree about https://issues.apache.org/jira/browse/OFBIZ-13068. As I said there, and knowing how it gets in such cases, I prefer to "keep this issue reopened and I'll not close your PR." I have created https://cwiki.apache.org/confluence/display/OFBIZ/Release+24.xx+Roadmap Unrelated : I also plan to close a lot of old pending Jira soon... Jacques
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Ah, last but not least: I think we should at least wait for Freemarker 2.3.33 that we successfully tested on demo. The vote should be soon, hence the release. Le 08/05/2024 à 20:47, Jacques Le Roux a écrit : Thanks to clarify Michael, Inline when needed... Le 08/05/2024 à 13:59, Michael Brohl a écrit : Hi everyone, my main point for having a roadmap and (if necessary) freezing trunk (for a short time) before creating a release branch in the future was to avoid the situation we have now: 1. we agreed to create a new release branch some time ago 2. there were some open tasks which blocked 1., mainly brought up by Jacques if I remember correctly I guess you speak about https://issues.apache.org/jira/browse/OFBIZ-12995 ? 3. suddenly there was a mass of new PR's which were merged in a hurry unneccesarily (my personal point of view), with some corrections soon after 4. 3. blocks 1. even further now because those changes are not complete/not rolled out for every component. I'm unsure that these changes are not complete for every component and even if it's the case it should not block the creation of a release branch. And if ever issues remain (not necessarily related to these changes) it's not a big deal to fix them once freezed. Instead of 3. we should have delayed merging those new features and worked on the blocking issues of 2. to be able to create a release from an almost stable trunk. So you speak about other known issues than https://issues.apache.org/jira/browse/OFBIZ-12995. Have you a clear view about them ? Else my answer to 4. should be reassure you, not a big deal. What helped me a lot in this recent experience is to review the demos logs (stable and trunk). I remember a project I worked on and was the last person to leave because they needed me to scrutinise the logs :) If we had a roadmap, I think we would have discussed 3. before it was happening and decided to wait merging those new features in favor of working on the creation of the new branch. That would be good, we used roadmaps in the past. Not all among them were successful or even followed. IIRW the 1st one was mostly successful: https://cwiki.apache.org/confluence/display/OFBIZ/4.x+Proposed+Roadmap+Items Others maybe less, just search "roadmap" in the wiki. Most were created by Sharan. Just to give an idea, here is one roadmap seriously discussed (most others were less). https://cwiki.apache.org/confluence/display/OFBIZ/Roadmap+Diagrams+-+In+Progress We also need to plan the time we want to give to fix the release branch before releasing. We use to finish it in the current year. From my OFBiz experience, it's just a plan anyway, ie it can be shorter or longer. My approach is simply about some structure, coordination and collaboration to reach goals the project has defined instead of going with the flow of incoming pull requests. I hope I was more clear now. Yes, thanks Jacques Thanks and regards, Michael Am 07.05.24 um 17:19 schrieb Pranay Pandey: Hi Daniel, I am in favor of creating a new release. After we create a new release, IMO we shouldn't be committing any new features there. This is critical that we limit the scope of release with ongoing development in the trunk. Best regards, Pranay Pandey On Tue, 7 May 2024 at 20:31, Daniel Watford wrote: Hi Jacques, I'm sorry, but I can't quite parse your question, 'What is the difference...'. Could you restate it another way? Are you asking what the difference is between enforcing a feature-freeze on trunk versus continuing to allow all changes to trunk whilst having a feature-freeze on a release branch (e.g. release-24.x)? I think it will be very difficult to define a prescriptive policy on what sort of fixes might be permitted on a release branch (e.g. release-24.x), but the availability of committers to do the work of applying patches to the branch might help us reach a de facto policy. I personally would want to avoid backporting changes from trunk to a release branch without good reason since I view this as duplicate work. Therefore I would only want to backport fixes from trunk to release where we have a defect that impacts users or if we felt that some new feature was very very very important to OFBiz that it couldn't wait for the future release branch. If it helps, the project has used the phrase 'This series has been stabilized with bug fixes since' on the Release History page: https://downloads.apache.org/ofbiz/. I would interpret this as the release branch was used to *stabilise* the features that were in trunk at the time the release branch was created. I fear that we all might be roughly in agreement but getting lost in the weeds of discussion. Should we go ahead and create a release-24.05 branch from trunk soon for the purpose of stabilising a future release? Or are there any important features that OFBiz developers want to see in trunk first? As far as which commits are later applied to the
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Thanks to clarify Michael, Inline when needed... Le 08/05/2024 à 13:59, Michael Brohl a écrit : Hi everyone, my main point for having a roadmap and (if necessary) freezing trunk (for a short time) before creating a release branch in the future was to avoid the situation we have now: 1. we agreed to create a new release branch some time ago 2. there were some open tasks which blocked 1., mainly brought up by Jacques if I remember correctly I guess you speak about https://issues.apache.org/jira/browse/OFBIZ-12995 ? 3. suddenly there was a mass of new PR's which were merged in a hurry unneccesarily (my personal point of view), with some corrections soon after 4. 3. blocks 1. even further now because those changes are not complete/not rolled out for every component. I'm unsure that these changes are not complete for every component and even if it's the case it should not block the creation of a release branch. And if ever issues remain (not necessarily related to these changes) it's not a big deal to fix them once freezed. Instead of 3. we should have delayed merging those new features and worked on the blocking issues of 2. to be able to create a release from an almost stable trunk. So you speak about other known issues than https://issues.apache.org/jira/browse/OFBIZ-12995. Have you a clear view about them ? Else my answer to 4. should be reassure you, not a big deal. What helped me a lot in this recent experience is to review the demos logs (stable and trunk). I remember a project I worked on and was the last person to leave because they needed me to scrutinise the logs :) If we had a roadmap, I think we would have discussed 3. before it was happening and decided to wait merging those new features in favor of working on the creation of the new branch. That would be good, we used roadmaps in the past. Not all among them were successful or even followed. IIRW the 1st one was mostly successful: https://cwiki.apache.org/confluence/display/OFBIZ/4.x+Proposed+Roadmap+Items Others maybe less, just search "roadmap" in the wiki. Most were created by Sharan. Just to give an idea, here is one roadmap seriously discussed (most others were less). https://cwiki.apache.org/confluence/display/OFBIZ/Roadmap+Diagrams+-+In+Progress We also need to plan the time we want to give to fix the release branch before releasing. We use to finish it in the current year. From my OFBiz experience, it's just a plan anyway, ie it can be shorter or longer. My approach is simply about some structure, coordination and collaboration to reach goals the project has defined instead of going with the flow of incoming pull requests. I hope I was more clear now. Yes, thanks Jacques Thanks and regards, Michael Am 07.05.24 um 17:19 schrieb Pranay Pandey: Hi Daniel, I am in favor of creating a new release. After we create a new release, IMO we shouldn't be committing any new features there. This is critical that we limit the scope of release with ongoing development in the trunk. Best regards, Pranay Pandey On Tue, 7 May 2024 at 20:31, Daniel Watford wrote: Hi Jacques, I'm sorry, but I can't quite parse your question, 'What is the difference...'. Could you restate it another way? Are you asking what the difference is between enforcing a feature-freeze on trunk versus continuing to allow all changes to trunk whilst having a feature-freeze on a release branch (e.g. release-24.x)? I think it will be very difficult to define a prescriptive policy on what sort of fixes might be permitted on a release branch (e.g. release-24.x), but the availability of committers to do the work of applying patches to the branch might help us reach a de facto policy. I personally would want to avoid backporting changes from trunk to a release branch without good reason since I view this as duplicate work. Therefore I would only want to backport fixes from trunk to release where we have a defect that impacts users or if we felt that some new feature was very very very important to OFBiz that it couldn't wait for the future release branch. If it helps, the project has used the phrase 'This series has been stabilized with bug fixes since' on the Release History page: https://downloads.apache.org/ofbiz/. I would interpret this as the release branch was used to *stabilise* the features that were in trunk at the time the release branch was created. I fear that we all might be roughly in agreement but getting lost in the weeds of discussion. Should we go ahead and create a release-24.05 branch from trunk soon for the purpose of stabilising a future release? Or are there any important features that OFBiz developers want to see in trunk first? As far as which commits are later applied to the release-24.05 branch, shall we leave that up to the committers at the time, but with a reminder that adding new features on the release-24.05 branch will increase the test burden before a public release can be
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Thanks for confirming Le 08/05/2024 à 15:45, Pranay Pandey a écrit : Hi Jacques, Yeah, I wanted to say that. As long as we are sure of test coverage, all the critical paths are working. Best regards, Pranay Pandey On Tue, 7 May 2024 at 22:11, Jacques Le Roux wrote: Ha sorry Pranay, I did not get your point, I guess you were discussing before frezzing the release branch, right? Then of course we can't guarantee to have fixed all known bugs. Only blocker bugs (decided by the reporter and discussed if needed) and of course security bugs are blocking a release. Jacques Le 07/05/2024 à 17:42, Jacques Le Roux a écrit : Hi Pranay, OK, but then only that? So far we backported any bug. So we would release a branch with bugs in? Le 07/05/2024 à 16:42, Pranay Pandey a écrit : Hi Jacques, what is a blocker bug, only security? I think it should also include anything broken on the UI or at the process level. Best regards, Pranay Pandey On Tue, 7 May 2024 at 19:48, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: What is the difference between freezing the trunk in a release-24.xx where the rule is no improvements but if a consensus agrees with? In other words, apart exceptions only bugs and not only blockers,as we did so far and the "new" proposition? Do we really wants to backport only blockerbugs? And then what is a blocker bug, only security? Somehow related, I also remember we freezed the trunk in few branches that we never released. 14.12 and 15.12 come to mind: https://ofbiz.apache.org/download.html HTH Jacques Le 07/05/2024 à 15:11, Pranay Pandey a écrit : Dear Daniel, Thank you for outlining the proposed release strategy for OFBiz. I liked the idea of creating a new branch from trunk named 'release-24.05' to address blockers for the upcoming release. I agree with Michael's proposal that targeting a release while working on the trunk is worth considering. Maintaining a consistent flow of new releases is crucial for project success. New releases with smaller changes are not only easier to adopt but also facilitate a smoother migration for existing ERP implementations, especially if users find value in the new features introduced. I believe this approach aligns well with the project's goals and will help in ensuring a structured and efficient release process. Let's continue the discussion on how we can further enhance this strategy to benefit the OFBiz development community. Thank you for your efforts in driving this conversation forward. Best regards, Pranay Pandey On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: Hello all, I'm a little confused by what the differences in opinions actually are in this thread. I think this is because the differences are minor and we are probably close to an agreement on how to proceed. Although there are not many of us involved in this conversation, it seems there is a desire to NOT impose any sort of feature freeze on the trunk branch. Instead we take the approach of creating a new branch from trunk, named something like 'release-24.05'. The purpose of this new branch is to address any issues that might be considered blockers for an upcoming OFBiz release. New features would not normally be applied to the release-24.05 branch, but exceptions to this rule would be considered on a case-by-case basis. Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and once addressed the release would be made public. A suitable tag - e.g. release-24.05.01 - would be applied to the release-24.05 branch to denote the commit that was publicly released. I believe the above describes how the OFBiz project has managed releases in the past. The discussions around a road map are orthogonal to the above release process, but would definitely help the OFBiz development community/PMC decide when would be an appropriate time to create a new release branch. It seems like the major project undertakings - such as the movement of Groovy Scripts within the source tree - have been completed, so now might be a good time to go ahead and create the release-24.05 branch from trunk. Thanks, Dan. On Mon, 6 May 2024 at 18:01, Jacques Le Roux < jacques.le.r...@les7arts.com wrote: Le 06/05/2024 à 18:35, Jacques Le Roux a écrit : BTW, to avoid to speak in the void. Again, what are those tasks precisely? And that are their situations? BTW, to avoid to speak in the void. Again, what are those tasks precisely? And WHAT are their situations? Sorry, typo -- Daniel Watford
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Jacques, Yeah, I wanted to say that. As long as we are sure of test coverage, all the critical paths are working. Best regards, Pranay Pandey On Tue, 7 May 2024 at 22:11, Jacques Le Roux wrote: > Ha sorry Pranay, > > I did not get your point, I guess you were discussing before frezzing the > release branch, right? > Then of course we can't guarantee to have fixed all known bugs. > Only blocker bugs (decided by the reporter and discussed if needed) and of > course security bugs are blocking a release. > > Jacques > > Le 07/05/2024 à 17:42, Jacques Le Roux a écrit : > > Hi Pranay, > > > > OK, but then only that? So far we backported any bug. So we would > release a branch with bugs in? > > > > Le 07/05/2024 à 16:42, Pranay Pandey a écrit : > >> Hi Jacques, > >> > >> what is a blocker bug, only security? > >> I think it should also include anything broken on the UI or at the > process > >> level. > >> > >> Best regards, > >> Pranay Pandey > >> > >> > >> On Tue, 7 May 2024 at 19:48, Jacques Le Roux < > jacques.le.r...@les7arts.com> > >> wrote: > >> > >>> What is the difference between freezing the trunk in a release-24.xx > where > >>> the rule is no improvements but if a consensus agrees with? In other > words, > >>> apart exceptions only bugs and not only blockers,as we did so far and > the > >>> "new" proposition? Do we really wants to backport only blockerbugs? And > >>> then > >>> what is a blocker bug, only security? > >>> > >>> Somehow related, I also remember we freezed the trunk in few branches > that > >>> we never released. 14.12 and 15.12 come to mind: > >>> https://ofbiz.apache.org/download.html > >>> > >>> HTH > >>> > >>> Jacques > >>> > >>> Le 07/05/2024 à 15:11, Pranay Pandey a écrit : > Dear Daniel, > > Thank you for outlining the proposed release strategy for OFBiz. I > liked > the idea of creating a new branch from trunk named 'release-24.05' to > address blockers for the upcoming release. > > I agree with Michael's proposal that targeting a release while > working on > the trunk is worth considering. Maintaining a consistent flow of new > releases is crucial for project success. New releases with smaller > >>> changes > are not only easier to adopt but also facilitate a smoother migration > for > existing ERP implementations, especially if users find value in the > new > features introduced. > > I believe this approach aligns well with the project's goals and will > >>> help > in ensuring a structured and efficient release process. Let's continue > >>> the > discussion on how we can further enhance this strategy to benefit the > >>> OFBiz > development community. > > Thank you for your efforts in driving this conversation forward. > > Best regards, > > Pranay Pandey > > > On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: > > > Hello all, > > > > I'm a little confused by what the differences in opinions actually > are > >>> in > > this thread. I think this is because the differences are minor and we > >>> are > > probably close to an agreement on how to proceed. > > > > Although there are not many of us involved in this conversation, it > >>> seems > > there is a desire to NOT impose any sort of feature freeze on the > trunk > > branch. > > > > Instead we take the approach of creating a new branch from trunk, > named > > something like 'release-24.05'. The purpose of this new branch is to > > address any issues that might be considered blockers for an upcoming > >>> OFBiz > > release. New features would not normally be applied to the > release-24.05 > > branch, but exceptions to this rule would be considered on a > >>> case-by-case > > basis. > > > > Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, > and > > once addressed the release would be made public. A suitable tag - > e.g. > > release-24.05.01 - would be applied to the release-24.05 branch to > >>> denote > > the commit that was publicly released. > > > > I believe the above describes how the OFBiz project has managed > >>> releases in > > the past. > > > > The discussions around a road map are orthogonal to the above release > > process, but would definitely help the OFBiz development > community/PMC > > decide when would be an appropriate time to create a new release > branch. > > > > It seems like the major project undertakings - such as the movement > of > > Groovy Scripts within the source tree - have been completed, so now > >>> might > > be a good time to go ahead and create the release-24.05 branch from > >>> trunk. > > Thanks, > > > > Dan. > > > > On Mon, 6 May 2024 at 18:01, Jacques Le Roux < > >>> jacques.le.r...@les7arts.com > > wrote: > > > >> Le 06/05/2024 à 18:35, Jacques Le Roux a écrit : > >>>
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Michael, Yeah, that makes a lot of sense to have a structure in place for sure. Best regards, Pranay Pandey On Wed, 8 May 2024 at 17:30, Michael Brohl wrote: > Hi everyone, > > my main point for having a roadmap and (if necessary) freezing trunk > (for a short time) before creating a release branch in the future was to > avoid the situation we have now: > > 1. we agreed to create a new release branch some time ago > > 2. there were some open tasks which blocked 1., mainly brought up by > Jacques if I remember correctly > > 3. suddenly there was a mass of new PR's which were merged in a hurry > unneccesarily (my personal point of view), with some corrections soon after > > 4. 3. blocks 1. even further now because those changes are not > complete/not rolled out for every component. > > Instead of 3. we should have delayed merging those new features and > worked on the blocking issues of 2. to be able to create a release from > an almost stable trunk. > > If we had a roadmap, I think we would have discussed 3. before it was > happening and decided to wait merging those new features in favor of > working on the creation of the new branch. > > My approach is simply about some structure, coordination and > collaboration to reach goals the project has defined instead of going > with the flow of incoming pull requests. > > I hope I was more clear now. > > Thanks and regards, > > Michael > > > Am 07.05.24 um 17:19 schrieb Pranay Pandey: > > Hi Daniel, > > > > I am in favor of creating a new release. > > > > After we create a new release, IMO we shouldn't be committing any new > > features there. > > > > This is critical that we limit the scope of release with ongoing > > development in the trunk. > > > > Best regards, > > Pranay Pandey > > > > > > On Tue, 7 May 2024 at 20:31, Daniel Watford wrote: > > > >> Hi Jacques, > >> > >> I'm sorry, but I can't quite parse your question, 'What is the > >> difference...'. Could you restate it another way? > >> > >> Are you asking what the difference is between enforcing a > feature-freeze on > >> trunk versus continuing to allow all changes to trunk whilst having a > >> feature-freeze on a release branch (e.g. release-24.x)? > >> > >> I think it will be very difficult to define a prescriptive policy on > what > >> sort of fixes might be permitted on a release branch (e.g. > release-24.x), > >> but the availability of committers to do the work of applying patches to > >> the branch might help us reach a de facto policy. > >> > >> I personally would want to avoid backporting changes from trunk to a > >> release branch without good reason since I view this as duplicate work. > >> Therefore I would only want to backport fixes from trunk to release > where > >> we have a defect that impacts users or if we felt that some new feature > was > >> very very very important to OFBiz that it couldn't wait for the future > >> release branch. > >> > >> If it helps, the project has used the phrase 'This series has been > >> stabilized with bug fixes since' on the Release History page: > >> https://downloads.apache.org/ofbiz/. I would interpret this as the > release > >> branch was used to *stabilise* the features that were in trunk at the > time > >> the release branch was created. > >> > >> I fear that we all might be roughly in agreement but getting lost in the > >> weeds of discussion. > >> > >> Should we go ahead and create a release-24.05 branch from trunk soon for > >> the purpose of stabilising a future release? Or are there any important > >> features that OFBiz developers want to see in trunk first? > >> > >> As far as which commits are later applied to the release-24.05 branch, > >> shall we leave that up to the committers at the time, but with a > reminder > >> that adding new features on the release-24.05 branch will increase the > test > >> burden before a public release can be made? > >> > >> Thanks, > >> > >> Dan. > >> > >> On Tue, 7 May 2024 at 15:20, Jacques Le Roux < > jacques.le.r...@les7arts.com > >> wrote: > >> > >>> What is the difference between freezing the trunk in a release-24.xx > >> where > >>> the rule is no improvements but if a consensus agrees with? In other > >> words, > >>> apart exceptions only bugs and not only blockers,as we did so far and > the > >>> "new" proposition? Do we really wants to backport only blockerbugs? And > >>> then > >>> what is a blocker bug, only security? > >>> > >>> Somehow related, I also remember we freezed the trunk in few branches > >> that > >>> we never released. 14.12 and 15.12 come to mind: > >>> https://ofbiz.apache.org/download.html > >>> > >>> HTH > >>> > >>> Jacques > >>> > >>> Le 07/05/2024 à 15:11, Pranay Pandey a écrit : > Dear Daniel, > > Thank you for outlining the proposed release strategy for OFBiz. I > >> liked > the idea of creating a new branch from trunk named 'release-24.05' to > address blockers for the upcoming release. > > I agree with Michael's proposal
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi everyone, my main point for having a roadmap and (if necessary) freezing trunk (for a short time) before creating a release branch in the future was to avoid the situation we have now: 1. we agreed to create a new release branch some time ago 2. there were some open tasks which blocked 1., mainly brought up by Jacques if I remember correctly 3. suddenly there was a mass of new PR's which were merged in a hurry unneccesarily (my personal point of view), with some corrections soon after 4. 3. blocks 1. even further now because those changes are not complete/not rolled out for every component. Instead of 3. we should have delayed merging those new features and worked on the blocking issues of 2. to be able to create a release from an almost stable trunk. If we had a roadmap, I think we would have discussed 3. before it was happening and decided to wait merging those new features in favor of working on the creation of the new branch. My approach is simply about some structure, coordination and collaboration to reach goals the project has defined instead of going with the flow of incoming pull requests. I hope I was more clear now. Thanks and regards, Michael Am 07.05.24 um 17:19 schrieb Pranay Pandey: Hi Daniel, I am in favor of creating a new release. After we create a new release, IMO we shouldn't be committing any new features there. This is critical that we limit the scope of release with ongoing development in the trunk. Best regards, Pranay Pandey On Tue, 7 May 2024 at 20:31, Daniel Watford wrote: Hi Jacques, I'm sorry, but I can't quite parse your question, 'What is the difference...'. Could you restate it another way? Are you asking what the difference is between enforcing a feature-freeze on trunk versus continuing to allow all changes to trunk whilst having a feature-freeze on a release branch (e.g. release-24.x)? I think it will be very difficult to define a prescriptive policy on what sort of fixes might be permitted on a release branch (e.g. release-24.x), but the availability of committers to do the work of applying patches to the branch might help us reach a de facto policy. I personally would want to avoid backporting changes from trunk to a release branch without good reason since I view this as duplicate work. Therefore I would only want to backport fixes from trunk to release where we have a defect that impacts users or if we felt that some new feature was very very very important to OFBiz that it couldn't wait for the future release branch. If it helps, the project has used the phrase 'This series has been stabilized with bug fixes since' on the Release History page: https://downloads.apache.org/ofbiz/. I would interpret this as the release branch was used to *stabilise* the features that were in trunk at the time the release branch was created. I fear that we all might be roughly in agreement but getting lost in the weeds of discussion. Should we go ahead and create a release-24.05 branch from trunk soon for the purpose of stabilising a future release? Or are there any important features that OFBiz developers want to see in trunk first? As far as which commits are later applied to the release-24.05 branch, shall we leave that up to the committers at the time, but with a reminder that adding new features on the release-24.05 branch will increase the test burden before a public release can be made? Thanks, Dan. On Tue, 7 May 2024 at 15:20, Jacques Le Roux What is the difference between freezing the trunk in a release-24.xx where the rule is no improvements but if a consensus agrees with? In other words, apart exceptions only bugs and not only blockers,as we did so far and the "new" proposition? Do we really wants to backport only blockerbugs? And then what is a blocker bug, only security? Somehow related, I also remember we freezed the trunk in few branches that we never released. 14.12 and 15.12 come to mind: https://ofbiz.apache.org/download.html HTH Jacques Le 07/05/2024 à 15:11, Pranay Pandey a écrit : Dear Daniel, Thank you for outlining the proposed release strategy for OFBiz. I liked the idea of creating a new branch from trunk named 'release-24.05' to address blockers for the upcoming release. I agree with Michael's proposal that targeting a release while working on the trunk is worth considering. Maintaining a consistent flow of new releases is crucial for project success. New releases with smaller changes are not only easier to adopt but also facilitate a smoother migration for existing ERP implementations, especially if users find value in the new features introduced. I believe this approach aligns well with the project's goals and will help in ensuring a structured and efficient release process. Let's continue the discussion on how we can further enhance this strategy to benefit the OFBiz development community. Thank you for your efforts in driving this conversation forward. Best
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
I totally agree, our enemy is regression and we should be very sure to avoid it. Le 07/05/2024 à 17:19, Pranay Pandey a écrit : Hi Daniel, I am in favor of creating a new release. After we create a new release, IMO we shouldn't be committing any new features there. This is critical that we limit the scope of release with ongoing development in the trunk. Best regards, Pranay Pandey On Tue, 7 May 2024 at 20:31, Daniel Watford wrote: Hi Jacques, I'm sorry, but I can't quite parse your question, 'What is the difference...'. Could you restate it another way? Are you asking what the difference is between enforcing a feature-freeze on trunk versus continuing to allow all changes to trunk whilst having a feature-freeze on a release branch (e.g. release-24.x)? I think it will be very difficult to define a prescriptive policy on what sort of fixes might be permitted on a release branch (e.g. release-24.x), but the availability of committers to do the work of applying patches to the branch might help us reach a de facto policy. I personally would want to avoid backporting changes from trunk to a release branch without good reason since I view this as duplicate work. Therefore I would only want to backport fixes from trunk to release where we have a defect that impacts users or if we felt that some new feature was very very very important to OFBiz that it couldn't wait for the future release branch. If it helps, the project has used the phrase 'This series has been stabilized with bug fixes since' on the Release History page: https://downloads.apache.org/ofbiz/. I would interpret this as the release branch was used to *stabilise* the features that were in trunk at the time the release branch was created. I fear that we all might be roughly in agreement but getting lost in the weeds of discussion. Should we go ahead and create a release-24.05 branch from trunk soon for the purpose of stabilising a future release? Or are there any important features that OFBiz developers want to see in trunk first? As far as which commits are later applied to the release-24.05 branch, shall we leave that up to the committers at the time, but with a reminder that adding new features on the release-24.05 branch will increase the test burden before a public release can be made? Thanks, Dan. On Tue, 7 May 2024 at 15:20, Jacques Le Roux What is the difference between freezing the trunk in a release-24.xx where the rule is no improvements but if a consensus agrees with? In other words, apart exceptions only bugs and not only blockers,as we did so far and the "new" proposition? Do we really wants to backport only blockerbugs? And then what is a blocker bug, only security? Somehow related, I also remember we freezed the trunk in few branches that we never released. 14.12 and 15.12 come to mind: https://ofbiz.apache.org/download.html HTH Jacques Le 07/05/2024 à 15:11, Pranay Pandey a écrit : Dear Daniel, Thank you for outlining the proposed release strategy for OFBiz. I liked the idea of creating a new branch from trunk named 'release-24.05' to address blockers for the upcoming release. I agree with Michael's proposal that targeting a release while working on the trunk is worth considering. Maintaining a consistent flow of new releases is crucial for project success. New releases with smaller changes are not only easier to adopt but also facilitate a smoother migration for existing ERP implementations, especially if users find value in the new features introduced. I believe this approach aligns well with the project's goals and will help in ensuring a structured and efficient release process. Let's continue the discussion on how we can further enhance this strategy to benefit the OFBiz development community. Thank you for your efforts in driving this conversation forward. Best regards, Pranay Pandey On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: Hello all, I'm a little confused by what the differences in opinions actually are in this thread. I think this is because the differences are minor and we are probably close to an agreement on how to proceed. Although there are not many of us involved in this conversation, it seems there is a desire to NOT impose any sort of feature freeze on the trunk branch. Instead we take the approach of creating a new branch from trunk, named something like 'release-24.05'. The purpose of this new branch is to address any issues that might be considered blockers for an upcoming OFBiz release. New features would not normally be applied to the release-24.05 branch, but exceptions to this rule would be considered on a case-by-case basis. Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and once addressed the release would be made public. A suitable tag - e.g. release-24.05.01 - would be applied to the release-24.05 branch to denote the commit that was publicly released. I believe the above describes how
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Ha sorry Pranay, I did not get your point, I guess you were discussing before frezzing the release branch, right? Then of course we can't guarantee to have fixed all known bugs. Only blocker bugs (decided by the reporter and discussed if needed) and of course security bugs are blocking a release. Jacques Le 07/05/2024 à 17:42, Jacques Le Roux a écrit : Hi Pranay, OK, but then only that? So far we backported any bug. So we would release a branch with bugs in? Le 07/05/2024 à 16:42, Pranay Pandey a écrit : Hi Jacques, what is a blocker bug, only security? I think it should also include anything broken on the UI or at the process level. Best regards, Pranay Pandey On Tue, 7 May 2024 at 19:48, Jacques Le Roux wrote: What is the difference between freezing the trunk in a release-24.xx where the rule is no improvements but if a consensus agrees with? In other words, apart exceptions only bugs and not only blockers,as we did so far and the "new" proposition? Do we really wants to backport only blockerbugs? And then what is a blocker bug, only security? Somehow related, I also remember we freezed the trunk in few branches that we never released. 14.12 and 15.12 come to mind: https://ofbiz.apache.org/download.html HTH Jacques Le 07/05/2024 à 15:11, Pranay Pandey a écrit : Dear Daniel, Thank you for outlining the proposed release strategy for OFBiz. I liked the idea of creating a new branch from trunk named 'release-24.05' to address blockers for the upcoming release. I agree with Michael's proposal that targeting a release while working on the trunk is worth considering. Maintaining a consistent flow of new releases is crucial for project success. New releases with smaller changes are not only easier to adopt but also facilitate a smoother migration for existing ERP implementations, especially if users find value in the new features introduced. I believe this approach aligns well with the project's goals and will help in ensuring a structured and efficient release process. Let's continue the discussion on how we can further enhance this strategy to benefit the OFBiz development community. Thank you for your efforts in driving this conversation forward. Best regards, Pranay Pandey On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: Hello all, I'm a little confused by what the differences in opinions actually are in this thread. I think this is because the differences are minor and we are probably close to an agreement on how to proceed. Although there are not many of us involved in this conversation, it seems there is a desire to NOT impose any sort of feature freeze on the trunk branch. Instead we take the approach of creating a new branch from trunk, named something like 'release-24.05'. The purpose of this new branch is to address any issues that might be considered blockers for an upcoming OFBiz release. New features would not normally be applied to the release-24.05 branch, but exceptions to this rule would be considered on a case-by-case basis. Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and once addressed the release would be made public. A suitable tag - e.g. release-24.05.01 - would be applied to the release-24.05 branch to denote the commit that was publicly released. I believe the above describes how the OFBiz project has managed releases in the past. The discussions around a road map are orthogonal to the above release process, but would definitely help the OFBiz development community/PMC decide when would be an appropriate time to create a new release branch. It seems like the major project undertakings - such as the movement of Groovy Scripts within the source tree - have been completed, so now might be a good time to go ahead and create the release-24.05 branch from trunk. Thanks, Dan. On Mon, 6 May 2024 at 18:01, Jacques Le Roux < jacques.le.r...@les7arts.com wrote: Le 06/05/2024 à 18:35, Jacques Le Roux a écrit : BTW, to avoid to speak in the void. Again, what are those tasks precisely? And that are their situations? BTW, to avoid to speak in the void. Again, what are those tasks precisely? And WHAT are their situations? Sorry, typo -- Daniel Watford
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Le 07/05/2024 à 17:01, Daniel Watford a écrit : Hi Jacques, I'm sorry, but I can't quite parse your question, 'What is the difference...'. Could you restate it another way? Simple, what is the process so far? We freeze the trunk into a release branch, says 24.xx in our case .05 seems short to me, though possible, as we need to check the situation for important things to be complete (or not), like OFBIZ-9350 I see the recent good will of Nicolas about that. We should not put the pression on anybody. Errors come from such situations. Then improvements are of course allowed in trunk but not in 24.xx apart exceptions agreed with a consensus (lazy or not, ie with a vote) As we use the CTR (Commit Then Review) mode it's always possible to revert before releasing, here 24.xx. So no known damage is theoretically possible. Blocker bugs are used to prevent a release as long as not fixed, as mentioned at : https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz There is no strict definition for a blocker bug. The reporter decides. It can be then discussed. Of course security is blocking, but we don't publish any information about it before releasing. Else it's a zero day for attackers. Are you asking what the difference is between enforcing a feature-freeze on trunk versus continuing to allow all changes to trunk whilst having a feature-freeze on a release branch (e.g. release-24.x)? I just try to explain that the current process is OK. We never feature-freezed the trunk but the upcoming release, again with very rare exceptions. So I'd like to know what should be changed if any. I think it will be very difficult to define a prescriptive policy on what sort of fixes might be permitted on a release branch (e.g. release-24.x), but the availability of committers to do the work of applying patches to the branch might help us reach a de facto policy. I agree about that. We have never been able to fix all bugs. Just blocker bugs block the release and that can be discussed. For blocker bugs, if we don't agree in Jira or PR we discuss it on dev ML to tend to a consensus. That can be a lazy one (no vote) if nobody is against. I personally would want to avoid backporting changes from trunk to a release branch without good reason since I view this as duplicate work. Only bugs are backported, except (very rare) exceptions Therefore I would only want to backport fixes from trunk to release where we have a defect that impacts users or if we felt that some new feature was very very very important to OFBiz that it couldn't wait for the future release branch. And if everybody is OK. A veto can block a commit (not a release) but that must be justified: https://www.apache.org/foundation/voting.html If it helps, the project has used the phrase 'This series has been stabilized with bug fixes since' on the Release History page: https://downloads.apache.org/ofbiz/. I would interpret this as the release branch was used to *stabilise* the features that were in trunk at the time the release branch was created. Yes that's it. We could maybe slightly change this sentence to explain that very important improvements may be rarely backported. I fear that we all might be roughly in agreement but getting lost in the weeds of discussion. Exactly, the devil is in the details and we get sometimes lost. Should we go ahead and create a release-24.05 branch from trunk soon for the purpose of stabilising a future release? Or are there any important features that OFBiz developers want to see in trunk first? That need to be discussed IMO. With clear cases, like OFBIZ-9350 but not only. We still need to find and agree about possible other cases I guess, hence 3 weeks being short to me. As far as which commits are later applied to the release-24.05 branch, shall we leave that up to the committers at the time, but with a reminder that adding new features on the release-24.05 branch will increase the test burden before a public release can be made? I prefer that we openly discuss that here (dev ML) before allowing improvements in release branches. I hope I'm clear :) Thanks Jacques Thanks, Dan. On Tue, 7 May 2024 at 15:20, Jacques Le Roux wrote: What is the difference between freezing the trunk in a release-24.xx where the rule is no improvements but if a consensus agrees with? In other words, apart exceptions only bugs and not only blockers,as we did so far and the "new" proposition? Do we really wants to backport only blockerbugs? And then what is a blocker bug, only security? Somehow related, I also remember we freezed the trunk in few branches that we never released. 14.12 and 15.12 come to mind: https://ofbiz.apache.org/download.html HTH Jacques Le 07/05/2024 à 15:11, Pranay Pandey a écrit : Dear Daniel, Thank you for outlining the proposed release strategy for OFBiz. I liked the idea of creating a new branch from trunk named 'release-24.05' to
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Pranay, OK, but then only that? So far we backported any bug. So we would release a branch with bugs in? Le 07/05/2024 à 16:42, Pranay Pandey a écrit : Hi Jacques, what is a blocker bug, only security? I think it should also include anything broken on the UI or at the process level. Best regards, Pranay Pandey On Tue, 7 May 2024 at 19:48, Jacques Le Roux wrote: What is the difference between freezing the trunk in a release-24.xx where the rule is no improvements but if a consensus agrees with? In other words, apart exceptions only bugs and not only blockers,as we did so far and the "new" proposition? Do we really wants to backport only blockerbugs? And then what is a blocker bug, only security? Somehow related, I also remember we freezed the trunk in few branches that we never released. 14.12 and 15.12 come to mind: https://ofbiz.apache.org/download.html HTH Jacques Le 07/05/2024 à 15:11, Pranay Pandey a écrit : Dear Daniel, Thank you for outlining the proposed release strategy for OFBiz. I liked the idea of creating a new branch from trunk named 'release-24.05' to address blockers for the upcoming release. I agree with Michael's proposal that targeting a release while working on the trunk is worth considering. Maintaining a consistent flow of new releases is crucial for project success. New releases with smaller changes are not only easier to adopt but also facilitate a smoother migration for existing ERP implementations, especially if users find value in the new features introduced. I believe this approach aligns well with the project's goals and will help in ensuring a structured and efficient release process. Let's continue the discussion on how we can further enhance this strategy to benefit the OFBiz development community. Thank you for your efforts in driving this conversation forward. Best regards, Pranay Pandey On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: Hello all, I'm a little confused by what the differences in opinions actually are in this thread. I think this is because the differences are minor and we are probably close to an agreement on how to proceed. Although there are not many of us involved in this conversation, it seems there is a desire to NOT impose any sort of feature freeze on the trunk branch. Instead we take the approach of creating a new branch from trunk, named something like 'release-24.05'. The purpose of this new branch is to address any issues that might be considered blockers for an upcoming OFBiz release. New features would not normally be applied to the release-24.05 branch, but exceptions to this rule would be considered on a case-by-case basis. Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and once addressed the release would be made public. A suitable tag - e.g. release-24.05.01 - would be applied to the release-24.05 branch to denote the commit that was publicly released. I believe the above describes how the OFBiz project has managed releases in the past. The discussions around a road map are orthogonal to the above release process, but would definitely help the OFBiz development community/PMC decide when would be an appropriate time to create a new release branch. It seems like the major project undertakings - such as the movement of Groovy Scripts within the source tree - have been completed, so now might be a good time to go ahead and create the release-24.05 branch from trunk. Thanks, Dan. On Mon, 6 May 2024 at 18:01, Jacques Le Roux < jacques.le.r...@les7arts.com wrote: Le 06/05/2024 à 18:35, Jacques Le Roux a écrit : BTW, to avoid to speak in the void. Again, what are those tasks precisely? And that are their situations? BTW, to avoid to speak in the void. Again, what are those tasks precisely? And WHAT are their situations? Sorry, typo -- Daniel Watford
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Daniel, I am in favor of creating a new release. After we create a new release, IMO we shouldn't be committing any new features there. This is critical that we limit the scope of release with ongoing development in the trunk. Best regards, Pranay Pandey On Tue, 7 May 2024 at 20:31, Daniel Watford wrote: > Hi Jacques, > > I'm sorry, but I can't quite parse your question, 'What is the > difference...'. Could you restate it another way? > > Are you asking what the difference is between enforcing a feature-freeze on > trunk versus continuing to allow all changes to trunk whilst having a > feature-freeze on a release branch (e.g. release-24.x)? > > I think it will be very difficult to define a prescriptive policy on what > sort of fixes might be permitted on a release branch (e.g. release-24.x), > but the availability of committers to do the work of applying patches to > the branch might help us reach a de facto policy. > > I personally would want to avoid backporting changes from trunk to a > release branch without good reason since I view this as duplicate work. > Therefore I would only want to backport fixes from trunk to release where > we have a defect that impacts users or if we felt that some new feature was > very very very important to OFBiz that it couldn't wait for the future > release branch. > > If it helps, the project has used the phrase 'This series has been > stabilized with bug fixes since' on the Release History page: > https://downloads.apache.org/ofbiz/. I would interpret this as the release > branch was used to *stabilise* the features that were in trunk at the time > the release branch was created. > > I fear that we all might be roughly in agreement but getting lost in the > weeds of discussion. > > Should we go ahead and create a release-24.05 branch from trunk soon for > the purpose of stabilising a future release? Or are there any important > features that OFBiz developers want to see in trunk first? > > As far as which commits are later applied to the release-24.05 branch, > shall we leave that up to the committers at the time, but with a reminder > that adding new features on the release-24.05 branch will increase the test > burden before a public release can be made? > > Thanks, > > Dan. > > On Tue, 7 May 2024 at 15:20, Jacques Le Roux > > wrote: > > > What is the difference between freezing the trunk in a release-24.xx > where > > the rule is no improvements but if a consensus agrees with? In other > words, > > apart exceptions only bugs and not only blockers,as we did so far and the > > "new" proposition? Do we really wants to backport only blockerbugs? And > > then > > what is a blocker bug, only security? > > > > Somehow related, I also remember we freezed the trunk in few branches > that > > we never released. 14.12 and 15.12 come to mind: > > https://ofbiz.apache.org/download.html > > > > HTH > > > > Jacques > > > > Le 07/05/2024 à 15:11, Pranay Pandey a écrit : > > > Dear Daniel, > > > > > > Thank you for outlining the proposed release strategy for OFBiz. I > liked > > > the idea of creating a new branch from trunk named 'release-24.05' to > > > address blockers for the upcoming release. > > > > > > I agree with Michael's proposal that targeting a release while working > on > > > the trunk is worth considering. Maintaining a consistent flow of new > > > releases is crucial for project success. New releases with smaller > > changes > > > are not only easier to adopt but also facilitate a smoother migration > for > > > existing ERP implementations, especially if users find value in the new > > > features introduced. > > > > > > I believe this approach aligns well with the project's goals and will > > help > > > in ensuring a structured and efficient release process. Let's continue > > the > > > discussion on how we can further enhance this strategy to benefit the > > OFBiz > > > development community. > > > > > > Thank you for your efforts in driving this conversation forward. > > > > > > Best regards, > > > > > > Pranay Pandey > > > > > > > > > On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: > > > > > >> Hello all, > > >> > > >> I'm a little confused by what the differences in opinions actually are > > in > > >> this thread. I think this is because the differences are minor and we > > are > > >> probably close to an agreement on how to proceed. > > >> > > >> Although there are not many of us involved in this conversation, it > > seems > > >> there is a desire to NOT impose any sort of feature freeze on the > trunk > > >> branch. > > >> > > >> Instead we take the approach of creating a new branch from trunk, > named > > >> something like 'release-24.05'. The purpose of this new branch is to > > >> address any issues that might be considered blockers for an upcoming > > OFBiz > > >> release. New features would not normally be applied to the > release-24.05 > > >> branch, but exceptions to this rule would be considered on a > > case-by-case > > >> basis. >
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Jacques, I'm sorry, but I can't quite parse your question, 'What is the difference...'. Could you restate it another way? Are you asking what the difference is between enforcing a feature-freeze on trunk versus continuing to allow all changes to trunk whilst having a feature-freeze on a release branch (e.g. release-24.x)? I think it will be very difficult to define a prescriptive policy on what sort of fixes might be permitted on a release branch (e.g. release-24.x), but the availability of committers to do the work of applying patches to the branch might help us reach a de facto policy. I personally would want to avoid backporting changes from trunk to a release branch without good reason since I view this as duplicate work. Therefore I would only want to backport fixes from trunk to release where we have a defect that impacts users or if we felt that some new feature was very very very important to OFBiz that it couldn't wait for the future release branch. If it helps, the project has used the phrase 'This series has been stabilized with bug fixes since' on the Release History page: https://downloads.apache.org/ofbiz/. I would interpret this as the release branch was used to *stabilise* the features that were in trunk at the time the release branch was created. I fear that we all might be roughly in agreement but getting lost in the weeds of discussion. Should we go ahead and create a release-24.05 branch from trunk soon for the purpose of stabilising a future release? Or are there any important features that OFBiz developers want to see in trunk first? As far as which commits are later applied to the release-24.05 branch, shall we leave that up to the committers at the time, but with a reminder that adding new features on the release-24.05 branch will increase the test burden before a public release can be made? Thanks, Dan. On Tue, 7 May 2024 at 15:20, Jacques Le Roux wrote: > What is the difference between freezing the trunk in a release-24.xx where > the rule is no improvements but if a consensus agrees with? In other words, > apart exceptions only bugs and not only blockers,as we did so far and the > "new" proposition? Do we really wants to backport only blockerbugs? And > then > what is a blocker bug, only security? > > Somehow related, I also remember we freezed the trunk in few branches that > we never released. 14.12 and 15.12 come to mind: > https://ofbiz.apache.org/download.html > > HTH > > Jacques > > Le 07/05/2024 à 15:11, Pranay Pandey a écrit : > > Dear Daniel, > > > > Thank you for outlining the proposed release strategy for OFBiz. I liked > > the idea of creating a new branch from trunk named 'release-24.05' to > > address blockers for the upcoming release. > > > > I agree with Michael's proposal that targeting a release while working on > > the trunk is worth considering. Maintaining a consistent flow of new > > releases is crucial for project success. New releases with smaller > changes > > are not only easier to adopt but also facilitate a smoother migration for > > existing ERP implementations, especially if users find value in the new > > features introduced. > > > > I believe this approach aligns well with the project's goals and will > help > > in ensuring a structured and efficient release process. Let's continue > the > > discussion on how we can further enhance this strategy to benefit the > OFBiz > > development community. > > > > Thank you for your efforts in driving this conversation forward. > > > > Best regards, > > > > Pranay Pandey > > > > > > On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: > > > >> Hello all, > >> > >> I'm a little confused by what the differences in opinions actually are > in > >> this thread. I think this is because the differences are minor and we > are > >> probably close to an agreement on how to proceed. > >> > >> Although there are not many of us involved in this conversation, it > seems > >> there is a desire to NOT impose any sort of feature freeze on the trunk > >> branch. > >> > >> Instead we take the approach of creating a new branch from trunk, named > >> something like 'release-24.05'. The purpose of this new branch is to > >> address any issues that might be considered blockers for an upcoming > OFBiz > >> release. New features would not normally be applied to the release-24.05 > >> branch, but exceptions to this rule would be considered on a > case-by-case > >> basis. > >> > >> Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and > >> once addressed the release would be made public. A suitable tag - e.g. > >> release-24.05.01 - would be applied to the release-24.05 branch to > denote > >> the commit that was publicly released. > >> > >> I believe the above describes how the OFBiz project has managed > releases in > >> the past. > >> > >> The discussions around a road map are orthogonal to the above release > >> process, but would definitely help the OFBiz development community/PMC > >> decide
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Jacques, what is a blocker bug, only security? I think it should also include anything broken on the UI or at the process level. Best regards, Pranay Pandey On Tue, 7 May 2024 at 19:48, Jacques Le Roux wrote: > What is the difference between freezing the trunk in a release-24.xx where > the rule is no improvements but if a consensus agrees with? In other words, > apart exceptions only bugs and not only blockers,as we did so far and the > "new" proposition? Do we really wants to backport only blockerbugs? And > then > what is a blocker bug, only security? > > Somehow related, I also remember we freezed the trunk in few branches that > we never released. 14.12 and 15.12 come to mind: > https://ofbiz.apache.org/download.html > > HTH > > Jacques > > Le 07/05/2024 à 15:11, Pranay Pandey a écrit : > > Dear Daniel, > > > > Thank you for outlining the proposed release strategy for OFBiz. I liked > > the idea of creating a new branch from trunk named 'release-24.05' to > > address blockers for the upcoming release. > > > > I agree with Michael's proposal that targeting a release while working on > > the trunk is worth considering. Maintaining a consistent flow of new > > releases is crucial for project success. New releases with smaller > changes > > are not only easier to adopt but also facilitate a smoother migration for > > existing ERP implementations, especially if users find value in the new > > features introduced. > > > > I believe this approach aligns well with the project's goals and will > help > > in ensuring a structured and efficient release process. Let's continue > the > > discussion on how we can further enhance this strategy to benefit the > OFBiz > > development community. > > > > Thank you for your efforts in driving this conversation forward. > > > > Best regards, > > > > Pranay Pandey > > > > > > On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: > > > >> Hello all, > >> > >> I'm a little confused by what the differences in opinions actually are > in > >> this thread. I think this is because the differences are minor and we > are > >> probably close to an agreement on how to proceed. > >> > >> Although there are not many of us involved in this conversation, it > seems > >> there is a desire to NOT impose any sort of feature freeze on the trunk > >> branch. > >> > >> Instead we take the approach of creating a new branch from trunk, named > >> something like 'release-24.05'. The purpose of this new branch is to > >> address any issues that might be considered blockers for an upcoming > OFBiz > >> release. New features would not normally be applied to the release-24.05 > >> branch, but exceptions to this rule would be considered on a > case-by-case > >> basis. > >> > >> Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and > >> once addressed the release would be made public. A suitable tag - e.g. > >> release-24.05.01 - would be applied to the release-24.05 branch to > denote > >> the commit that was publicly released. > >> > >> I believe the above describes how the OFBiz project has managed > releases in > >> the past. > >> > >> The discussions around a road map are orthogonal to the above release > >> process, but would definitely help the OFBiz development community/PMC > >> decide when would be an appropriate time to create a new release branch. > >> > >> It seems like the major project undertakings - such as the movement of > >> Groovy Scripts within the source tree - have been completed, so now > might > >> be a good time to go ahead and create the release-24.05 branch from > trunk. > >> > >> Thanks, > >> > >> Dan. > >> > >> On Mon, 6 May 2024 at 18:01, Jacques Le Roux < > jacques.le.r...@les7arts.com > >> wrote: > >> > >>> Le 06/05/2024 à 18:35, Jacques Le Roux a écrit : > BTW, to avoid to speak in the void. Again, what are those tasks > >>> precisely? And that are their situations? > >>> > >>> BTW, to avoid to speak in the void. Again, what are those tasks > >> precisely? > >>> And WHAT are their situations? > >>> > >>> Sorry, typo > >>> > >>> > >> -- > >> Daniel Watford > >>
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
What is the difference between freezing the trunk in a release-24.xx where the rule is no improvements but if a consensus agrees with? In other words, apart exceptions only bugs and not only blockers,as we did so far and the "new" proposition? Do we really wants to backport only blockerbugs? And then what is a blocker bug, only security? Somehow related, I also remember we freezed the trunk in few branches that we never released. 14.12 and 15.12 come to mind: https://ofbiz.apache.org/download.html HTH Jacques Le 07/05/2024 à 15:11, Pranay Pandey a écrit : Dear Daniel, Thank you for outlining the proposed release strategy for OFBiz. I liked the idea of creating a new branch from trunk named 'release-24.05' to address blockers for the upcoming release. I agree with Michael's proposal that targeting a release while working on the trunk is worth considering. Maintaining a consistent flow of new releases is crucial for project success. New releases with smaller changes are not only easier to adopt but also facilitate a smoother migration for existing ERP implementations, especially if users find value in the new features introduced. I believe this approach aligns well with the project's goals and will help in ensuring a structured and efficient release process. Let's continue the discussion on how we can further enhance this strategy to benefit the OFBiz development community. Thank you for your efforts in driving this conversation forward. Best regards, Pranay Pandey On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: Hello all, I'm a little confused by what the differences in opinions actually are in this thread. I think this is because the differences are minor and we are probably close to an agreement on how to proceed. Although there are not many of us involved in this conversation, it seems there is a desire to NOT impose any sort of feature freeze on the trunk branch. Instead we take the approach of creating a new branch from trunk, named something like 'release-24.05'. The purpose of this new branch is to address any issues that might be considered blockers for an upcoming OFBiz release. New features would not normally be applied to the release-24.05 branch, but exceptions to this rule would be considered on a case-by-case basis. Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and once addressed the release would be made public. A suitable tag - e.g. release-24.05.01 - would be applied to the release-24.05 branch to denote the commit that was publicly released. I believe the above describes how the OFBiz project has managed releases in the past. The discussions around a road map are orthogonal to the above release process, but would definitely help the OFBiz development community/PMC decide when would be an appropriate time to create a new release branch. It seems like the major project undertakings - such as the movement of Groovy Scripts within the source tree - have been completed, so now might be a good time to go ahead and create the release-24.05 branch from trunk. Thanks, Dan. On Mon, 6 May 2024 at 18:01, Jacques Le Roux Le 06/05/2024 à 18:35, Jacques Le Roux a écrit : BTW, to avoid to speak in the void. Again, what are those tasks precisely? And that are their situations? BTW, to avoid to speak in the void. Again, what are those tasks precisely? And WHAT are their situations? Sorry, typo -- Daniel Watford
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Dear Daniel, Thank you for outlining the proposed release strategy for OFBiz. I liked the idea of creating a new branch from trunk named 'release-24.05' to address blockers for the upcoming release. I agree with Michael's proposal that targeting a release while working on the trunk is worth considering. Maintaining a consistent flow of new releases is crucial for project success. New releases with smaller changes are not only easier to adopt but also facilitate a smoother migration for existing ERP implementations, especially if users find value in the new features introduced. I believe this approach aligns well with the project's goals and will help in ensuring a structured and efficient release process. Let's continue the discussion on how we can further enhance this strategy to benefit the OFBiz development community. Thank you for your efforts in driving this conversation forward. Best regards, Pranay Pandey On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: > Hello all, > > I'm a little confused by what the differences in opinions actually are in > this thread. I think this is because the differences are minor and we are > probably close to an agreement on how to proceed. > > Although there are not many of us involved in this conversation, it seems > there is a desire to NOT impose any sort of feature freeze on the trunk > branch. > > Instead we take the approach of creating a new branch from trunk, named > something like 'release-24.05'. The purpose of this new branch is to > address any issues that might be considered blockers for an upcoming OFBiz > release. New features would not normally be applied to the release-24.05 > branch, but exceptions to this rule would be considered on a case-by-case > basis. > > Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and > once addressed the release would be made public. A suitable tag - e.g. > release-24.05.01 - would be applied to the release-24.05 branch to denote > the commit that was publicly released. > > I believe the above describes how the OFBiz project has managed releases in > the past. > > The discussions around a road map are orthogonal to the above release > process, but would definitely help the OFBiz development community/PMC > decide when would be an appropriate time to create a new release branch. > > It seems like the major project undertakings - such as the movement of > Groovy Scripts within the source tree - have been completed, so now might > be a good time to go ahead and create the release-24.05 branch from trunk. > > Thanks, > > Dan. > > On Mon, 6 May 2024 at 18:01, Jacques Le Roux > > wrote: > > > Le 06/05/2024 à 18:35, Jacques Le Roux a écrit : > > > BTW, to avoid to speak in the void. Again, what are those tasks > > precisely? And that are their situations? > > > > BTW, to avoid to speak in the void. Again, what are those tasks > precisely? > > And WHAT are their situations? > > > > Sorry, typo > > > > > > -- > Daniel Watford >
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hello all, I'm a little confused by what the differences in opinions actually are in this thread. I think this is because the differences are minor and we are probably close to an agreement on how to proceed. Although there are not many of us involved in this conversation, it seems there is a desire to NOT impose any sort of feature freeze on the trunk branch. Instead we take the approach of creating a new branch from trunk, named something like 'release-24.05'. The purpose of this new branch is to address any issues that might be considered blockers for an upcoming OFBiz release. New features would not normally be applied to the release-24.05 branch, but exceptions to this rule would be considered on a case-by-case basis. Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and once addressed the release would be made public. A suitable tag - e.g. release-24.05.01 - would be applied to the release-24.05 branch to denote the commit that was publicly released. I believe the above describes how the OFBiz project has managed releases in the past. The discussions around a road map are orthogonal to the above release process, but would definitely help the OFBiz development community/PMC decide when would be an appropriate time to create a new release branch. It seems like the major project undertakings - such as the movement of Groovy Scripts within the source tree - have been completed, so now might be a good time to go ahead and create the release-24.05 branch from trunk. Thanks, Dan. On Mon, 6 May 2024 at 18:01, Jacques Le Roux wrote: > Le 06/05/2024 à 18:35, Jacques Le Roux a écrit : > > BTW, to avoid to speak in the void. Again, what are those tasks > precisely? And that are their situations? > > BTW, to avoid to speak in the void. Again, what are those tasks precisely? > And WHAT are their situations? > > Sorry, typo > > -- Daniel Watford
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Le 06/05/2024 à 18:35, Jacques Le Roux a écrit : BTW, to avoid to speak in the void. Again, what are those tasks precisely? And that are their situations? BTW, to avoid to speak in the void. Again, what are those tasks precisely? And WHAT are their situations? Sorry, typo
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
BTW, to avoid to speak in the void. Again, what are those tasks precisely? And that are their situations? Le 06/05/2024 à 18:24, Jacques Le Roux a écrit : Hi Stephen, As I can see it, because of the number of people really involved in such tasks. Jacques Le 06/05/2024 à 17:45, Stephen Davidson a écrit : Good afternoon. Maybe I am missing something, but why can't WIP be executed finished & stabilized on the Release Branch and then merged to Trunk? Regards, Steve On 5/6/24 04:07, Jacques Le Roux wrote: Hi, We should 1st clearly identify WIPs in trunk and at which stage they are each. We can't wait and complicate the situation before that. Jacques Le 06/05/2024 à 10:36, gil.portenseigne a écrit : Hi, I feel like Michael, when there are 'in progress' work in trunk, when we create a release branch for stabilisation, the remaining work of such task will only be in trunk (since those are improvements). But delaying release is not good when we look at the name of our last release that show the 2018 year. The concession we could agree on should be to identify such tasks to let user know the partial improvements contained in the release. i.e. creating release branch + roadmap :) WDYT ? Gil On 22/04/24 04:12, Jacques Le Roux wrote: Hi Guys, Without getting into details, I tend to disagree with your propositions. I can't see why we would change our very simple way of doing. When we freeze a branch, the activity can continue on trunk. It does not interfere with the new release branch. The only variable is the period we allow before releasing the branch. Then, that depends on the breaking changes (or not) we recently made. Why should we change? I fear it will rather introduce complications. Please keep it simple. TIA for your explanations on simple reasons to change : what is wrong with our current way of doing? Jacques Le 22/04/2024 à 09:37, Daniel Watford a écrit : Hi Michael, I'm broadly in favour of your proposal, but perhaps with a slightly different 'shape' to the approach. I too was hoping that we could freeze trunk before creating a 24.x release branch as I was concerned about the about of duplicate work (backporting) that might need to be done if we took a 24.x release branch earlier in the year, but alas trunk marches on and I think it will be difficult to mandate a period of release-related-only changes in trunk. Instead I think, as Deepak mentioned, we should take a new 24.x branch to use for stabilisation - with tags denoting the actual releases along that branch. It feels that the large projects - such as groovy-scripts migration - have completed which should reduce the amount of rework that would have to take place simultaneously on trunk and the 24.x release branch. >From your comments I infer that you may be suggesting yearly releases. I think this is a good idea as it will allow the introduction of major new functionalities in trunk without needing to wait years for them to become generally accessible. Without more frequent releases we will have the temptation to port major functionality into already existing release branches which might take a large amount of effort and could introduce instability between minor releases. I hope my inference reflects your intended proposal! :) Yes to a roadmap. Thanks, Dan. On Sun, 21 Apr 2024 at 14:50, Michael Brohl wrote: Hi everyone, we agreed to work towards a stabilizing trunk to be able to create a 24.x release branch, which means we have to thoroughly decide which changes should go into trunk. There are currently lots of changes going into trunk with PR's created and rapidly be merged into the codebase. This causes potential for errors being introduced in trunk, potentially leading to delay the creation of the next release branch even more. In my opinion, this is contraproductive to the goal of creating a stable release branch 24.x in due time. I propose to make a decision to have a code freeze for new features and improvements and focus on bug fixes until we have created a 24.x branch. I also propose that we start organizing a roadmap to give the community some guidelines where to focus and which main features can be expected in the next release branches. It might also give developers some goals to provide the features according to planned releases and maybe work together to reach those project goals. For example, there are some initiatives for Tomcat migration, introducing REST functionality in the framework and others which we can assign to future release branches. Maybe we can have a plan for a 25.x release branch which introduces those features. I do not intend to make this an unflexible roadmap, means there can always be more planned/unplanned features be added to the roadmap and be discussed. We should have some deadlines for new features though, just to be able to create the next feature branch in the planned time periods. What do you think? Best regards, Michael Brohl ecomify GmbH -
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Stephen, As I can see it, because of the number of people really involved in such tasks. Jacques Le 06/05/2024 à 17:45, Stephen Davidson a écrit : Good afternoon. Maybe I am missing something, but why can't WIP be executed finished & stabilized on the Release Branch and then merged to Trunk? Regards, Steve On 5/6/24 04:07, Jacques Le Roux wrote: Hi, We should 1st clearly identify WIPs in trunk and at which stage they are each. We can't wait and complicate the situation before that. Jacques Le 06/05/2024 à 10:36, gil.portenseigne a écrit : Hi, I feel like Michael, when there are 'in progress' work in trunk, when we create a release branch for stabilisation, the remaining work of such task will only be in trunk (since those are improvements). But delaying release is not good when we look at the name of our last release that show the 2018 year. The concession we could agree on should be to identify such tasks to let user know the partial improvements contained in the release. i.e. creating release branch + roadmap :) WDYT ? Gil On 22/04/24 04:12, Jacques Le Roux wrote: Hi Guys, Without getting into details, I tend to disagree with your propositions. I can't see why we would change our very simple way of doing. When we freeze a branch, the activity can continue on trunk. It does not interfere with the new release branch. The only variable is the period we allow before releasing the branch. Then, that depends on the breaking changes (or not) we recently made. Why should we change? I fear it will rather introduce complications. Please keep it simple. TIA for your explanations on simple reasons to change : what is wrong with our current way of doing? Jacques Le 22/04/2024 à 09:37, Daniel Watford a écrit : Hi Michael, I'm broadly in favour of your proposal, but perhaps with a slightly different 'shape' to the approach. I too was hoping that we could freeze trunk before creating a 24.x release branch as I was concerned about the about of duplicate work (backporting) that might need to be done if we took a 24.x release branch earlier in the year, but alas trunk marches on and I think it will be difficult to mandate a period of release-related-only changes in trunk. Instead I think, as Deepak mentioned, we should take a new 24.x branch to use for stabilisation - with tags denoting the actual releases along that branch. It feels that the large projects - such as groovy-scripts migration - have completed which should reduce the amount of rework that would have to take place simultaneously on trunk and the 24.x release branch. >From your comments I infer that you may be suggesting yearly releases. I think this is a good idea as it will allow the introduction of major new functionalities in trunk without needing to wait years for them to become generally accessible. Without more frequent releases we will have the temptation to port major functionality into already existing release branches which might take a large amount of effort and could introduce instability between minor releases. I hope my inference reflects your intended proposal! :) Yes to a roadmap. Thanks, Dan. On Sun, 21 Apr 2024 at 14:50, Michael Brohl wrote: Hi everyone, we agreed to work towards a stabilizing trunk to be able to create a 24.x release branch, which means we have to thoroughly decide which changes should go into trunk. There are currently lots of changes going into trunk with PR's created and rapidly be merged into the codebase. This causes potential for errors being introduced in trunk, potentially leading to delay the creation of the next release branch even more. In my opinion, this is contraproductive to the goal of creating a stable release branch 24.x in due time. I propose to make a decision to have a code freeze for new features and improvements and focus on bug fixes until we have created a 24.x branch. I also propose that we start organizing a roadmap to give the community some guidelines where to focus and which main features can be expected in the next release branches. It might also give developers some goals to provide the features according to planned releases and maybe work together to reach those project goals. For example, there are some initiatives for Tomcat migration, introducing REST functionality in the framework and others which we can assign to future release branches. Maybe we can have a plan for a 25.x release branch which introduces those features. I do not intend to make this an unflexible roadmap, means there can always be more planned/unplanned features be added to the roadmap and be discussed. We should have some deadlines for new features though, just to be able to create the next feature branch in the planned time periods. What do you think? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Good afternoon. Maybe I am missing something, but why can't WIP be executed finished & stabilized on the Release Branch and then merged to Trunk? Regards, Steve On 5/6/24 04:07, Jacques Le Roux wrote: Hi, We should 1st clearly identify WIPs in trunk and at which stage they are each. We can't wait and complicate the situation before that. Jacques Le 06/05/2024 à 10:36, gil.portenseigne a écrit : Hi, I feel like Michael, when there are 'in progress' work in trunk, when we create a release branch for stabilisation, the remaining work of such task will only be in trunk (since those are improvements). But delaying release is not good when we look at the name of our last release that show the 2018 year. The concession we could agree on should be to identify such tasks to let user know the partial improvements contained in the release. i.e. creating release branch + roadmap :) WDYT ? Gil On 22/04/24 04:12, Jacques Le Roux wrote: Hi Guys, Without getting into details, I tend to disagree with your propositions. I can't see why we would change our very simple way of doing. When we freeze a branch, the activity can continue on trunk. It does not interfere with the new release branch. The only variable is the period we allow before releasing the branch. Then, that depends on the breaking changes (or not) we recently made. Why should we change? I fear it will rather introduce complications. Please keep it simple. TIA for your explanations on simple reasons to change : what is wrong with our current way of doing? Jacques Le 22/04/2024 à 09:37, Daniel Watford a écrit : Hi Michael, I'm broadly in favour of your proposal, but perhaps with a slightly different 'shape' to the approach. I too was hoping that we could freeze trunk before creating a 24.x release branch as I was concerned about the about of duplicate work (backporting) that might need to be done if we took a 24.x release branch earlier in the year, but alas trunk marches on and I think it will be difficult to mandate a period of release-related-only changes in trunk. Instead I think, as Deepak mentioned, we should take a new 24.x branch to use for stabilisation - with tags denoting the actual releases along that branch. It feels that the large projects - such as groovy-scripts migration - have completed which should reduce the amount of rework that would have to take place simultaneously on trunk and the 24.x release branch. >From your comments I infer that you may be suggesting yearly releases. I think this is a good idea as it will allow the introduction of major new functionalities in trunk without needing to wait years for them to become generally accessible. Without more frequent releases we will have the temptation to port major functionality into already existing release branches which might take a large amount of effort and could introduce instability between minor releases. I hope my inference reflects your intended proposal! :) Yes to a roadmap. Thanks, Dan. On Sun, 21 Apr 2024 at 14:50, Michael Brohl wrote: Hi everyone, we agreed to work towards a stabilizing trunk to be able to create a 24.x release branch, which means we have to thoroughly decide which changes should go into trunk. There are currently lots of changes going into trunk with PR's created and rapidly be merged into the codebase. This causes potential for errors being introduced in trunk, potentially leading to delay the creation of the next release branch even more. In my opinion, this is contraproductive to the goal of creating a stable release branch 24.x in due time. I propose to make a decision to have a code freeze for new features and improvements and focus on bug fixes until we have created a 24.x branch. I also propose that we start organizing a roadmap to give the community some guidelines where to focus and which main features can be expected in the next release branches. It might also give developers some goals to provide the features according to planned releases and maybe work together to reach those project goals. For example, there are some initiatives for Tomcat migration, introducing REST functionality in the framework and others which we can assign to future release branches. Maybe we can have a plan for a 25.x release branch which introduces those features. I do not intend to make this an unflexible roadmap, means there can always be more planned/unplanned features be added to the roadmap and be discussed. We should have some deadlines for new features though, just to be able to create the next feature branch in the planned time periods. What do you think? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi, We should 1st clearly identify WIPs in trunk and at which stage they are each. We can't wait and complicate the situation before that. Jacques Le 06/05/2024 à 10:36, gil.portenseigne a écrit : Hi, I feel like Michael, when there are 'in progress' work in trunk, when we create a release branch for stabilisation, the remaining work of such task will only be in trunk (since those are improvements). But delaying release is not good when we look at the name of our last release that show the 2018 year. The concession we could agree on should be to identify such tasks to let user know the partial improvements contained in the release. i.e. creating release branch + roadmap :) WDYT ? Gil On 22/04/24 04:12, Jacques Le Roux wrote: Hi Guys, Without getting into details, I tend to disagree with your propositions. I can't see why we would change our very simple way of doing. When we freeze a branch, the activity can continue on trunk. It does not interfere with the new release branch. The only variable is the period we allow before releasing the branch. Then, that depends on the breaking changes (or not) we recently made. Why should we change? I fear it will rather introduce complications. Please keep it simple. TIA for your explanations on simple reasons to change : what is wrong with our current way of doing? Jacques Le 22/04/2024 à 09:37, Daniel Watford a écrit : Hi Michael, I'm broadly in favour of your proposal, but perhaps with a slightly different 'shape' to the approach. I too was hoping that we could freeze trunk before creating a 24.x release branch as I was concerned about the about of duplicate work (backporting) that might need to be done if we took a 24.x release branch earlier in the year, but alas trunk marches on and I think it will be difficult to mandate a period of release-related-only changes in trunk. Instead I think, as Deepak mentioned, we should take a new 24.x branch to use for stabilisation - with tags denoting the actual releases along that branch. It feels that the large projects - such as groovy-scripts migration - have completed which should reduce the amount of rework that would have to take place simultaneously on trunk and the 24.x release branch. >From your comments I infer that you may be suggesting yearly releases. I think this is a good idea as it will allow the introduction of major new functionalities in trunk without needing to wait years for them to become generally accessible. Without more frequent releases we will have the temptation to port major functionality into already existing release branches which might take a large amount of effort and could introduce instability between minor releases. I hope my inference reflects your intended proposal! :) Yes to a roadmap. Thanks, Dan. On Sun, 21 Apr 2024 at 14:50, Michael Brohl wrote: Hi everyone, we agreed to work towards a stabilizing trunk to be able to create a 24.x release branch, which means we have to thoroughly decide which changes should go into trunk. There are currently lots of changes going into trunk with PR's created and rapidly be merged into the codebase. This causes potential for errors being introduced in trunk, potentially leading to delay the creation of the next release branch even more. In my opinion, this is contraproductive to the goal of creating a stable release branch 24.x in due time. I propose to make a decision to have a code freeze for new features and improvements and focus on bug fixes until we have created a 24.x branch. I also propose that we start organizing a roadmap to give the community some guidelines where to focus and which main features can be expected in the next release branches. It might also give developers some goals to provide the features according to planned releases and maybe work together to reach those project goals. For example, there are some initiatives for Tomcat migration, introducing REST functionality in the framework and others which we can assign to future release branches. Maybe we can have a plan for a 25.x release branch which introduces those features. I do not intend to make this an unflexible roadmap, means there can always be more planned/unplanned features be added to the roadmap and be discussed. We should have some deadlines for new features though, just to be able to create the next feature branch in the planned time periods. What do you think? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi, I feel like Michael, when there are 'in progress' work in trunk, when we create a release branch for stabilisation, the remaining work of such task will only be in trunk (since those are improvements). But delaying release is not good when we look at the name of our last release that show the 2018 year. The concession we could agree on should be to identify such tasks to let user know the partial improvements contained in the release. i.e. creating release branch + roadmap :) WDYT ? Gil On 22/04/24 04:12, Jacques Le Roux wrote: > Hi Guys, > > Without getting into details, I tend to disagree with your propositions. I > can't see why we would change our very simple way of doing. > > When we freeze a branch, the activity can continue on trunk. It does not > interfere with the new release branch. > The only variable is the period we allow before releasing the branch. Then, > that depends on the breaking changes (or not) we recently made. > > Why should we change? I fear it will rather introduce complications. Please > keep it simple. > > TIA for your explanations on simple reasons to change : what is wrong with > our current way of doing? > > Jacques > > Le 22/04/2024 à 09:37, Daniel Watford a écrit : > > Hi Michael, > > > > I'm broadly in favour of your proposal, but perhaps with a slightly > > different 'shape' to the approach. > > > > I too was hoping that we could freeze trunk before creating a 24.x release > > branch as I was concerned about the about of duplicate work (backporting) > > that might need to be done if we took a 24.x release branch earlier in the > > year, but alas trunk marches on and I think it will be difficult to > > mandate a period of release-related-only changes in trunk. > > > > Instead I think, as Deepak mentioned, we should take a new 24.x branch to > > use for stabilisation - with tags denoting the actual releases along that > > branch. It feels that the large projects - such as groovy-scripts migration > > - have completed which should reduce the amount of rework that would have > > to take place simultaneously on trunk and the 24.x release branch. > > > > >From your comments I infer that you may be suggesting yearly releases. I > > think this is a good idea as it will allow the introduction of major new > > functionalities in trunk without needing to wait years for them to become > > generally accessible. Without more frequent releases we will have the > > temptation to port major functionality into already existing release > > branches which might take a large amount of effort and could introduce > > instability between minor releases. I hope my inference reflects your > > intended proposal! :) > > > > Yes to a roadmap. > > > > Thanks, > > > > Dan. > > > > > > On Sun, 21 Apr 2024 at 14:50, Michael Brohl > > wrote: > > > > > Hi everyone, > > > > > > we agreed to work towards a stabilizing trunk to be able to create a > > > 24.x release branch, which means we have to thoroughly decide which > > > changes should go into trunk. There are currently lots of changes going > > > into trunk with PR's created and rapidly be merged into the codebase. > > > This causes potential for errors being introduced in trunk, potentially > > > leading to delay the creation of the next release branch even more. > > > > > > In my opinion, this is contraproductive to the goal of creating a stable > > > release branch 24.x in due time. > > > > > > I propose to make a decision to have a code freeze for new features and > > > improvements and focus on bug fixes until we have created a 24.x branch. > > > > > > I also propose that we start organizing a roadmap to give the community > > > some guidelines where to focus and which main features can be expected > > > in the next release branches. It might also give developers some goals > > > to provide the features according to planned releases and maybe work > > > together to reach those project goals. > > > > > > For example, there are some initiatives for Tomcat migration, > > > introducing REST functionality in the framework and others which we can > > > assign to future release branches. Maybe we can have a plan for a 25.x > > > release branch which introduces those features. > > > > > > I do not intend to make this an unflexible roadmap, means there can > > > always be more planned/unplanned features be added to the roadmap and be > > > discussed. We should have some deadlines for new features though, just > > > to be able to create the next feature branch in the planned time periods. > > > > > > What do you think? > > > > > > Best regards, > > > > > > Michael Brohl > > > > > > ecomify GmbH - www.ecomify.de > > > > > > > > >
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hello, Why don't create the release branch now ? Nicolas Le 21/04/2024 à 15:49, Michael Brohl a écrit : Hi everyone, we agreed to work towards a stabilizing trunk to be able to create a 24.x release branch, which means we have to thoroughly decide which changes should go into trunk. There are currently lots of changes going into trunk with PR's created and rapidly be merged into the codebase. This causes potential for errors being introduced in trunk, potentially leading to delay the creation of the next release branch even more. In my opinion, this is contraproductive to the goal of creating a stable release branch 24.x in due time. I propose to make a decision to have a code freeze for new features and improvements and focus on bug fixes until we have created a 24.x branch. I also propose that we start organizing a roadmap to give the community some guidelines where to focus and which main features can be expected in the next release branches. It might also give developers some goals to provide the features according to planned releases and maybe work together to reach those project goals. For example, there are some initiatives for Tomcat migration, introducing REST functionality in the framework and others which we can assign to future release branches. Maybe we can have a plan for a 25.x release branch which introduces those features. I do not intend to make this an unflexible roadmap, means there can always be more planned/unplanned features be added to the roadmap and be discussed. We should have some deadlines for new features though, just to be able to create the next feature branch in the planned time periods. What do you think? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Le 22/04/2024 à 16:12, Jacques Le Roux a écrit : Without getting into details, I tend to disagree with your propositions. I start writing that. Maybe I should rather have started by saying that I don't understand why we should change our (simple) way of doing.
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Guys, Without getting into details, I tend to disagree with your propositions. I can't see why we would change our very simple way of doing. When we freeze a branch, the activity can continue on trunk. It does not interfere with the new release branch. The only variable is the period we allow before releasing the branch. Then, that depends on the breaking changes (or not) we recently made. Why should we change? I fear it will rather introduce complications. Please keep it simple. TIA for your explanations on simple reasons to change : what is wrong with our current way of doing? Jacques Le 22/04/2024 à 09:37, Daniel Watford a écrit : Hi Michael, I'm broadly in favour of your proposal, but perhaps with a slightly different 'shape' to the approach. I too was hoping that we could freeze trunk before creating a 24.x release branch as I was concerned about the about of duplicate work (backporting) that might need to be done if we took a 24.x release branch earlier in the year, but alas trunk marches on and I think it will be difficult to mandate a period of release-related-only changes in trunk. Instead I think, as Deepak mentioned, we should take a new 24.x branch to use for stabilisation - with tags denoting the actual releases along that branch. It feels that the large projects - such as groovy-scripts migration - have completed which should reduce the amount of rework that would have to take place simultaneously on trunk and the 24.x release branch. >From your comments I infer that you may be suggesting yearly releases. I think this is a good idea as it will allow the introduction of major new functionalities in trunk without needing to wait years for them to become generally accessible. Without more frequent releases we will have the temptation to port major functionality into already existing release branches which might take a large amount of effort and could introduce instability between minor releases. I hope my inference reflects your intended proposal! :) Yes to a roadmap. Thanks, Dan. On Sun, 21 Apr 2024 at 14:50, Michael Brohl wrote: Hi everyone, we agreed to work towards a stabilizing trunk to be able to create a 24.x release branch, which means we have to thoroughly decide which changes should go into trunk. There are currently lots of changes going into trunk with PR's created and rapidly be merged into the codebase. This causes potential for errors being introduced in trunk, potentially leading to delay the creation of the next release branch even more. In my opinion, this is contraproductive to the goal of creating a stable release branch 24.x in due time. I propose to make a decision to have a code freeze for new features and improvements and focus on bug fixes until we have created a 24.x branch. I also propose that we start organizing a roadmap to give the community some guidelines where to focus and which main features can be expected in the next release branches. It might also give developers some goals to provide the features according to planned releases and maybe work together to reach those project goals. For example, there are some initiatives for Tomcat migration, introducing REST functionality in the framework and others which we can assign to future release branches. Maybe we can have a plan for a 25.x release branch which introduces those features. I do not intend to make this an unflexible roadmap, means there can always be more planned/unplanned features be added to the roadmap and be discussed. We should have some deadlines for new features though, just to be able to create the next feature branch in the planned time periods. What do you think? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Michael, I'm broadly in favour of your proposal, but perhaps with a slightly different 'shape' to the approach. I too was hoping that we could freeze trunk before creating a 24.x release branch as I was concerned about the about of duplicate work (backporting) that might need to be done if we took a 24.x release branch earlier in the year, but alas trunk marches on and I think it will be difficult to mandate a period of release-related-only changes in trunk. Instead I think, as Deepak mentioned, we should take a new 24.x branch to use for stabilisation - with tags denoting the actual releases along that branch. It feels that the large projects - such as groovy-scripts migration - have completed which should reduce the amount of rework that would have to take place simultaneously on trunk and the 24.x release branch. >From your comments I infer that you may be suggesting yearly releases. I think this is a good idea as it will allow the introduction of major new functionalities in trunk without needing to wait years for them to become generally accessible. Without more frequent releases we will have the temptation to port major functionality into already existing release branches which might take a large amount of effort and could introduce instability between minor releases. I hope my inference reflects your intended proposal! :) Yes to a roadmap. Thanks, Dan. On Sun, 21 Apr 2024 at 14:50, Michael Brohl wrote: > Hi everyone, > > we agreed to work towards a stabilizing trunk to be able to create a > 24.x release branch, which means we have to thoroughly decide which > changes should go into trunk. There are currently lots of changes going > into trunk with PR's created and rapidly be merged into the codebase. > This causes potential for errors being introduced in trunk, potentially > leading to delay the creation of the next release branch even more. > > In my opinion, this is contraproductive to the goal of creating a stable > release branch 24.x in due time. > > I propose to make a decision to have a code freeze for new features and > improvements and focus on bug fixes until we have created a 24.x branch. > > I also propose that we start organizing a roadmap to give the community > some guidelines where to focus and which main features can be expected > in the next release branches. It might also give developers some goals > to provide the features according to planned releases and maybe work > together to reach those project goals. > > For example, there are some initiatives for Tomcat migration, > introducing REST functionality in the framework and others which we can > assign to future release branches. Maybe we can have a plan for a 25.x > release branch which introduces those features. > > I do not intend to make this an unflexible roadmap, means there can > always be more planned/unplanned features be added to the roadmap and be > discussed. We should have some deadlines for new features though, just > to be able to create the next feature branch in the planned time periods. > > What do you think? > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > -- Daniel Watford
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Sounds good to me!! I wanted to propose a change in process regarding the stabilization of code releases. Instead of restricting commits directly to the trunk, I suggest creating a branch named "24.04" or "24.05" (depending on the release version) specifically for stabilization purposes. This branch will serve as a dedicated space for stabilizing the code without impacting ongoing work in the trunk. By implementing this approach, we can focus on stabilizing the release branch independently while allowing continuous development to proceed on the trunk. The only additional overhead will be the need to backport bug fixes from the release branch to the trunk or vice versa. I believe this strategy will help us maintain a more organized and efficient development workflow, ensuring that our releases are stable and reliable without disrupting ongoing development efforts. Thanks & Regards -- Deepak Dixit ofbiz.apache.org On Sun, Apr 21, 2024 at 7:20 PM Michael Brohl wrote: > Hi everyone, > > we agreed to work towards a stabilizing trunk to be able to create a > 24.x release branch, which means we have to thoroughly decide which > changes should go into trunk. There are currently lots of changes going > into trunk with PR's created and rapidly be merged into the codebase. > This causes potential for errors being introduced in trunk, potentially > leading to delay the creation of the next release branch even more. > > In my opinion, this is contraproductive to the goal of creating a stable > release branch 24.x in due time. > > I propose to make a decision to have a code freeze for new features and > improvements and focus on bug fixes until we have created a 24.x branch. > > I also propose that we start organizing a roadmap to give the community > some guidelines where to focus and which main features can be expected > in the next release branches. It might also give developers some goals > to provide the features according to planned releases and maybe work > together to reach those project goals. > > For example, there are some initiatives for Tomcat migration, > introducing REST functionality in the framework and others which we can > assign to future release branches. Maybe we can have a plan for a 25.x > release branch which introduces those features. > > I do not intend to make this an unflexible roadmap, means there can > always be more planned/unplanned features be added to the roadmap and be > discussed. We should have some deadlines for new features though, just > to be able to create the next feature branch in the planned time periods. > > What do you think? > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > >
[PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi everyone, we agreed to work towards a stabilizing trunk to be able to create a 24.x release branch, which means we have to thoroughly decide which changes should go into trunk. There are currently lots of changes going into trunk with PR's created and rapidly be merged into the codebase. This causes potential for errors being introduced in trunk, potentially leading to delay the creation of the next release branch even more. In my opinion, this is contraproductive to the goal of creating a stable release branch 24.x in due time. I propose to make a decision to have a code freeze for new features and improvements and focus on bug fixes until we have created a 24.x branch. I also propose that we start organizing a roadmap to give the community some guidelines where to focus and which main features can be expected in the next release branches. It might also give developers some goals to provide the features according to planned releases and maybe work together to reach those project goals. For example, there are some initiatives for Tomcat migration, introducing REST functionality in the framework and others which we can assign to future release branches. Maybe we can have a plan for a 25.x release branch which introduces those features. I do not intend to make this an unflexible roadmap, means there can always be more planned/unplanned features be added to the roadmap and be discussed. We should have some deadlines for new features though, just to be able to create the next feature branch in the planned time periods. What do you think? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de
