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 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<d...@foomoo.co.uk> 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 > >> -- Daniel Watford
