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<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
