I'm actually routinely backporting fixes to both branches (18 and 22).
Most of the time it's easy, but with moved groovy files it will be really more
work.
Le 28/07/2023 à 17:53, Daniel Watford a écrit :
I'm not familiar with that bug, but I am of the opinion that branch 22.01
is abandoned, therefore there is no target branch to backport a bug to.
We also are not accepting bug fixes into the 18 branch - Perhaps this is a
decision we should reconsidered since it means we have no path to migrate
users towards a fix in case of a serious bug. But once again, I am mindful
that we have limited time to do additional work - perhaps this is a subject
for a different thread.
On Fri, 28 Jul 2023 at 16:46, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
Also please consider these comments: https://s.apache.org/fcpi3
Le 28/07/2023 à 17:32, Jacques Le Roux a écrit :
Hi Daniel,
Ho many time do you think we need?
Maybe a month is indeed short. Though actually the changes are pretty
simple and we should not cross much issues
Le 28/07/2023 à 17:17, Daniel Watford a écrit :
Hi Jacques,
Apologies if I've misunderstood your meaning, but I don't think we
should
rush to create a 23.xx branch.
Following such a large refactor, we are likely to find issues in our
use of
groovy scripts over the coming weeks. If we go ahead and create a new
23.xx
branch from trunk too soon we will have to fix those groovy script
issues
in trunk and the new branch - increasing the amount of work needed.
I agree that we want to get a 23.xx branch in place once we are happy
that
the groovy script refactor work has completed and had a chance to have a
few fixes applied.
Thanks,
Dan.
On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux <
jacques.le.r...@les7arts.com>
wrote:
Le 03/05/2023 à 09:45, Jacopo Cappellato a écrit :
On Tue, May 2, 2023 at 9:17 AM Daniel Watford <d...@foomoo.co.uk>
wrote:
[...]
I'll ask one more question (and then run for cover!): Rather than
carry
out
this work twice. What if we abandon the 22.01 release and instead
make
a
new release branch (23.xx) soon after moving the Groovy sources?
Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.
Jacopo
Hi,
In relation with [OFBIZ-12813] Refactor groovy folder structure and add
package declaration
As soon as a groovy file is modified, and especially moved, in trunk
(framework is done, plugins is waiting), it will be more hand work to
backport.
So I think we should indeed quickly think about creating a 23.xx
(23.09?)
release branch. Else if will be soon a nightmare to backport fixes.
Jacques
