Hi Jacques, I would like to see a delay of at least 4 weeks to give interested parties a chance to exercise the parts of OFBiz they are most familiar with.
I'm happy to be challenged on this, though. Choosing a reasonable amount of time is a balance between duplicating work when resources are limited, and moving the project forward. I don't think there is an obvious answer to this one, so the maintainers will need to propose the branch when they feel the time is right. Although not expected to be the case, if we were to find lots of issues, then we could delay creating the 23.xx branch accordingly. On Fri, 28 Jul 2023 at 16:32, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote: > 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 > >> > >> > >> > -- Daniel Watford
