Ah, last but not least: I think we should at least wait for Freemarker 2.3.33 that we successfully tested on demo. The vote should be soon, hence the
release.
Le 08/05/2024 à 20:47, Jacques Le Roux a écrit :
Thanks to clarify Michael,
Inline when needed...
Le 08/05/2024 à 13:59, Michael Brohl a écrit :
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
I guess you speak about https://issues.apache.org/jira/browse/OFBIZ-12995 ?
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.
I'm unsure that these changes are not complete for every component and even if
it's the case it should not block the creation of a release branch.
And if ever issues remain (not necessarily related to these changes) it's not a
big deal to fix them once freezed.
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.
So you speak about other known issues than
https://issues.apache.org/jira/browse/OFBIZ-12995.
Have you a clear view about them ? Else my answer to 4. should be reassure you,
not a big deal.
What helped me a lot in this recent experience is to review the demos logs
(stable and trunk).
I remember a project I worked on and was the last person to leave because they
needed me to scrutinise the logs :)
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.
That would be good, we used roadmaps in the past. Not all among them were
successful or even followed.
IIRW the 1st one was mostly successful:
https://cwiki.apache.org/confluence/display/OFBIZ/4.x+Proposed+Roadmap+Items
Others maybe less, just search "roadmap" in the wiki. Most were created by Sharan. Just to give an idea, here is one roadmap seriously discussed
(most others were less).
https://cwiki.apache.org/confluence/display/OFBIZ/Roadmap+Diagrams+-+In+Progress
We also need to plan the time we want to give to fix the release branch before
releasing. We use to finish it in the current year.
From my OFBiz experience, it's just a plan anyway, ie it can be shorter or
longer.
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.
Yes, thanks
Jacques
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
