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