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 <michael.br...@ecomify.de> 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 <d...@foomoo.co.uk> 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 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 > >> >
