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
