date:20240508

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

2024-05-08 Thread Jacques Le Roux

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