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
