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 <jacques.le.r...@les7arts.com>
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<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
> >>>>>
>

Reply via email to