Thanks, Michael. I’m fine with waiting until the 26.11 release branch is created.
However, I don’t see much value in creating a feature branch and removing the applications from it now. Keeping that branch up to date would create unnecessary merge conflicts and additional maintenance overhead. For the initial stage, I believe the simplest approach is to create a separate applications repository. Moving the applications into the plugins repository would introduce additional complexity, particularly because some plugins depend on the applications. We can certainly consider merging the applications into the plugins repository at a later stage, once the community is ready and we have a clear plan for handling these dependencies. Thanks & Regards -- Deepak Dixit ofbiz.apache.org On Wed, Jul 22, 2026 at 3:22 PM Michael Brohl <[email protected]> wrote: > Hi Deepak, > > we already had a voted decision [1] for it, so I don't see why we should > open this discussion again. > > To save time, we can also create a new applications repo, remove the > applications in another feature branch (not in trunk!) and prepare > everything to be merged after release branch 26.11 is created. This > would imply that the feature branch is held up-to-date by the > developer(s) in charge. > > As said elsewhere, I don't see the need to rush things being done in trunk. > > Other aspects: > > 1. we should have a good migration guide and tools to make things easier > for users to migrate. > > 2. Thinking more about it I ask myself, why we should have another repo > for applications? > I assume that the mechanism will work very similar to the plugins > integration, so why don't we move the applications to plugins? > We can use alreaday existing tools and gradle tasks and would have > a clear structure with 2 repos instead of 3 and the plugins will become > more value. > > Maybe we should classify those plugins as "core" or "officially > maintained by the community" vs. "unmaintained" to have a clear > distinction. > > Other than that, I don't see much value in a 3rd repo, but maybe I > miss something important? > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > [1] https://lists.apache.org/thread/vhpp6kyp3x2z98ls0d62t2843tr0fhsk > > > Michael Brohl > Geschäftsführer > > ecomify GmbH, Stralsunder Straße 63, 33605 Bielefeld > Fon: +49 521 448157-90 | Fax: +49 521 448157-99 | www.ecomify.de > Court Registration: Amtsgericht Bielefeld, HRB 41683 | CEO: Martin Becker, > Michael Brohl > > Am 22.07.26 um 06:10 schrieb Deepak Dixit: > > Thanks, Nicolas and Michael, for your input. > > > > Creating the release branch first makes sense, as we cannot freeze the > > trunk for four months while waiting for the release. We also should not > > prevent contributors from pushing new features or other code changes > during > > this period. > > > > We have two options: > > > > 1. Create a branch named release26.11, stabilize it, and release it > in > > November. > > 2. Create a release26.07 branch, stabilize it, and release it as > soon as > > it is ready rather than waiting until November. > > > > I’m open to either option!! > > Thanks & Regards > > -- > > Deepak Dixit > > ofbiz.apache.org > > > > > > On Tue, Jul 21, 2026 at 1:14 PM Nicolas Malin via dev < > [email protected]> > > wrote: > > > >> Hello, > >> > >> After giving it some thought, release 26.11 and git separation are two > >> separate topics. > >> > >> To move forward, I suggest creating the release branch 26.11 and make > >> the git separation later. > >> > >> If you know how to clone or fork OFBiz from git repo, it means that you > >> are an advanced user. Therefore, you can choose to keep your release > >> 26.11 as before (nothing changed) or start with the new repo structure > >> billed as experimental. > >> > >> For the archive release, nothing has changed. > >> > >> So for me the priority is creating the release branch first, as we can't > >> freeze trunk for 4 months to wait for the release > >> > >> Nicolas > >> > >> Le 14/07/2026 à 10:30, Michael Brohl a écrit : > >>> Hi Deepak, > >>> > >>> I'm in favor of keeping it calm and don't rush fundamental changes. > >>> > >>> The change puts pressure on users who will have to change their code > >>> management, pipelines and deployment processes. > >>> > >>> We already have a lot of changes going on. > >>> > >>> So for me it's the next step AFTER release 26.11. > >>> > >>> Thanks and regards, > >>> > >>> Michael Brohl > >>> > >>> ecomify GmbH - www.ecomify.de > >>> > >>> > >>> Am 06.07.26 um 11:38 schrieb Deepak Dixit: > >>>> Hi Nicolas, > >>>> > >>>> I would like to target this for the *26.11* release. We’ll have > several > >>>> months before the November release to thoroughly test the application > >>>> separation work and ensure the release is stable. > >>>> > >>>> I believe this gives us sufficient time to identify and address any > >>>> issues > >>>> before the release is finalized. > >>>> > >>>> Thanks & Regards > >>>> -- > >>>> Deepak Dixit > >>>> ofbiz.apache.org > >>>> > >>>> > >>>> On Mon, Jul 6, 2026 at 1:54 PM Nicolas Malin via dev > >>>> <[email protected]> > >>>> wrote: > >>>> > >>>>> Hello Deepak, > >>>>> > >>>>> Thanks for all your efforts on this way, I suggest to realize the git > >>>>> separation after the release 26.11 creation. > >>>>> > >>>>> I imagine that you already had in mind anyway, but just want to make > >>>>> sure > >>>>> :) > >>>>> > >>>>> Nicolas > >>>>> > >>>>> Le 01/07/2026 à 09:53, Deepak Dixit a écrit : > >>>>>> Hi all, > >>>>>> > >>>>>> As a follow-up to the recent discussion on separating the > applications > >>>>> from > >>>>>> the framework, I’d like to propose creating a new Git repository > named > >>>>>> *ofbiz-applications*. > >>>>>> > >>>>>> Discussion thread: > >>>>>> https://lists.apache.org/thread/8rvtlfyo3hqg1kgmmo9t9tybw5vjfqt9 > >>>>>> > >>>>>> Over the past several weeks, we’ve completed the dependency cleanup > >>>>>> work > >>>>>> tracked under *OFBIZ-13305*. The framework no longer has runtime > >>>>>> dependencies on the applications, and the remaining references have > >>>>> either > >>>>>> been removed or migrated into the framework where appropriate. > >>>>>> > >>>>>> The goals of creating a separate repository are to: > >>>>>> > >>>>>> - Decouple the applications from the framework. > >>>>>> - Allow the framework and applications to evolve > independently. > >>>>>> - Simplify the framework repository and make it easier to use > >>>>>> as a > >>>>>> standalone foundation. > >>>>>> - Make framework upgrades significantly easier for adopters. > >>>>>> > >>>>>> Today, one of the biggest challenges when upgrading OFBiz is merging > >>>>>> changes in the application layer, where business logic often > conflicts > >>>>> with > >>>>>> custom implementations. > >>>>>> > >>>>>> As a result, many adopters postpone framework upgrades, making it > more > >>>>>> difficult to benefit from the latest framework improvements, bug > >>>>>> fixes, > >>>>>> performance enhancements, and, most importantly, security fixes. > >>>>>> > >>>>>> By separating the applications from the framework, adopters will be > >>>>>> able > >>>>> to > >>>>>> upgrade the framework independently while keeping their customized > >>>>>> application code unchanged. This will significantly reduce merge > >>>>> conflicts, > >>>>>> simplify framework upgrades, and encourage users to stay current > >>>>>> with the > >>>>>> latest framework releases, including *critical security* updates. > >>>>>> > >>>>>> If any additional dependencies are discovered after the split, we > can > >>>>>> address them through follow-up JIRA issues without blocking the > >>>>> repository > >>>>>> separation. > >>>>>> > >>>>>> Unless there are any objections, I’d like to proceed with creating > the > >>>>> new > >>>>>> *ofbiz-applications* Git repository and then begin migrating the > >>>>>> application modules from the ofbiz-framework repository. > >>>>>> > >>>>>> Please share your feedback or concerns. > >>>>>> > >>>>>> Thanks > >>>>>> -- > >>>>>> Deepak Dixit > >>>>>> ofbiz.apache.org > >>>>>> >
