SpringBoot 4 is already at M2 preview, also Spring 7 is approaching. I think we should consider an upgrade in the foreseeable future.
This would come with Java 21 as minimal version.
All in all this would be a breaking change, thus out of scope for version 1.x. Maybe we could use this as a starting point for defining the scope of a potential v2.0?
Further major upgrades I would consider:
Hi @kthoms
I’d be very careful with a version 2.0. We promise stability and our messaging was that projects migrating to Operaton can rely on a version 1.x being present for some time.
I’m not sure if Spring Boot 4 would be a breaking change. The Starters for 4 are not backwards compatible due to package changes, but nothing would prevent us from maintaining the 3 and 4 starters in parallel. Camunda had a baseline of Java 11 for everything, but enforced Java 17 for the Spring Boot 3 starter, we could do something similar.
Would upgrading the internal dependencies really be a breaking change to the projects using Operaton? Should a major version change in any framework Operaton uses internally and provides an integration for require a breaking change in our own API? Would we then maintain 1.x and 2.x in parallel?
JUnit6 can be provided as an addtional tool, as we do with 4 and 5 now. The Maven version the project uses internally is of no concern to the projects using Operaton, is it?
Technically it would surely be possible to support both, as it was done with JavaEE / JakartaEE. I would favor a clear separation. I don’t really like to mix Java and major dependencies in one development stream.
You want to stay on Java 17 / SpringBoot 3.x / Camunda 7 max. compatibility? Go with Operaton 1.x
Java 21 / new Spring stack? Go with Operaton 2.x.
Rgd. JUnit 6, Maven 4: Agreed, this does not neccessarily be scoped for a 2.x version.
We have also the deprecated API that needs to be cleaned up some day.
I’m thinking also about a message: What is your plan beyond maintenance of 1.x? It is easier to communicate the need for a major version if there are major dependency changes involved. 1.x would be a LTS version, which we likely need.
This is all very early and there will be nothing in this direction be done without having the resources to support different development branches. But why not starting thinking about it?
Talking about 2.0 is completely fine, I just got the impression of a way more immediate timeline, as you mentioned Spring 7 and Spring Boot 4 which are due to be released in November, probably. Spring Boot 3 will be EOL in mid 2026 (for the community edition), sorry if my post sounded too defensive. I will open a different thread for the Spring Boot 4 support, I already have made some experiments on my local machine to see what has to be done.
And I do think it is good to have a plan for Operaton beyond 1.x, but if I was a customer / end user I’d ask what is in it for me for migrating a Framework to a new major version and having to put in the work and money for doing so. Maybe a good angle would be how the API could be made better with Java 21 features, or things which could be improved when removing old technology in a way that integration of Operaton would be easier. We should not cater to users who use an outdated / unsupported stack as our main demographic, but I’m not sure we should introduce breaking changes if we cannot show any benefits which are worth it
Earlier I wrote someting wrong, the Spring Boot 4 migration guide states "Spring Boot 4.0 requires Java 17 or later. ", so that won’t be a problem.
I agree that for a major release there should be enough reason to put effort into it. That handle could be: Security. As long as the Spring stack provides security patches users are good to go with 1.x. I’m not sure if I would like to support both Spring stacks in one major release. But you said you made already experience with that.
We also have to distinguish between existing and new users. New users likely want to be on the latest stack. Hey, you are not on SpringBoot 4, but competitor XY is, let’s go with them! For me this is a major technology decision reason. But Spring alone isn’t enough.
And how about the web apps? Would we drop the old ones and replace them with the new in a 1.x stream? Or have both? My feeling here would be that a replacement of the old apps by new ones would best fit for a 2.x version.
The 1.x stream would anyways stay for a while and receive updates. For existing users that are happy with the existing stack this should be the way to go. There is already some demand for LTS support and frequent security updates for the 1.x release.
I do see that such a 2.x release is something on the long term, maybe mid/end 2026. But if we collect now enough topics and decide what will be on 1.x and what on 2.x, then we slowly can shape the roadmap.
I recently migrated some libraries to spring-boot-4.0.0-M1. Due to the changes made to modularize Spring Boot, it would not be feasible to support both 3.5.x and 4.x at the same time. The preliminary Migration Guide has a note for projects like ours:
Due to the modularization effort, supporting both Spring Boot 3 and Spring Boot 4 is strongly discouraged.
I would suggest to go for the Spring Boot 4.x migration in mid 2026 (when spring boot 3.5.x is end of OSS support).
The only drawback is that Spring Boot 3.5 has an extra long LTS (commercial support only) Lifetime: 2032-06! But since it is not OSS, we cannot build upon that.
I would propose that Operaton 2.0 is more than just a baseline upgrade. The scope could include:
Baseline modernization
API cleanup and safety
New features
Database support
Dependency strategy
Security
Observability
Build and developer experience (tbd)
Versioning strategy
Thank you @ungerts for this compilation of topics. This is mostly reflecting the major scope items.
I think first we have to come to a decision that we will have 2 development streams in the future after the 1.0 release. This for sure adds complexity, but trying to manage this on one stream would be even harder.
The step towards 2.x does not necessarily mean larger changes to customers. Maybe those that embed Operaton in their Spring Boot application have to update their applications to SB4, but those wanting to stay on SB3 just stick to Operaton 1.x. Besides this obvious major change, I don’t think that most of what you mentioned does mean huge migration efforts to the vast majority of users.
Raising the minimal Java version is not a clear must to me. We observe our first upstream dependencies requiring Java 21 (JRuby 10), making this transparent by also providing a major version update. Deciding on the minimal Java version for 2.x is another point on the decision list.
How do we come further? Maybe decide first on a general roadmap and then assign topics to 1.x or 2.x?
My vision would be a version 2.x somewhere in late 2026. I sense that is also your thought.
@ungerts The topics you raise sound like great candidates for Operaton 2.0, there is a lot of value in that list, thanks for writing it down!
I thought about this some more this week and I’m still not entirely convinced that the Spring / Boot update should be tied to a major release. In my opinion, Camunda made a mistake in calling the projects just “engine-spring” and “spring-boot-starter”. They are integration libraries for other frameworks, but they were coupled to the Camunda versioning scheme. This makes sense, as they encapsulate the public API, make some parts available via Spring Beans, proxy the configuration of Camunda / Operaton. This means that it is important to know which release of these two models belong to which version, and we should keep that. By ommitting the target frameworks version in the module name we imply that there is one Spring version and one Spring Boot version that offiicially belongs to Operaton. This also means, that users cannot upgrade a certain Operaton version without adapting the embedding framework. As Operaton is one library among many, this is a behavior I would dislike as a user. I am not keen on the dependencies of my application dictating the environment it needs in such a manner, especially if the core of this library / integration is not coupled to Spring Framework / Spring Boot at all. As we don’t only have one integration for Spring, but also integrations for Quarkus, Jakarta EE / CDI, I wonder if breaking changes in those integrations would also lead to us requiring a major version update if we try and apply this approach to everything equally.
A solution I can imagine is creating new modules “engine-spring-7” and “spring-boot-4-starter” in the current main version, and keeping this versioning scheme for futere releases, “engine-spring-7”, “spring-boot-5-starter”, etc. The unversioned modules could be deprecated and phased out, once Spring 6 is EOL. This naming would make it clearer to the end users how the dependencies worked, would provide them with more freedom in selecting their own libraries and would enable us to react faster to major version updates in those frameworks we integrate into.
This also would be relevant to the estimated roadmap with a late 2026 release. If we take this long to release Operaton 2.0 and if we need 2.0 to include Spring Boot 4, then we force the users to stick with an unsupported Framework, as Spring Boot 3 will be EOL in June. For the clients I have worked with in the past this would be not acceptable.
I would like to get broader input on these thoughts, especially from teams using Operaton / Camunda in production in a Spring Boot app. I’d be really interested in the focus and opinions those users have.
I support the idea of creating separate modules for Framework Integration X. The engine itself forms the basis of the project, so a major version update indicating breaking changes should imply changes to the engine itself, rather than to its integrations.
So it seems that tendency for Spring Boot 4 is to try adding it as new module within the multi-module project besides Spring Boot 3. I’m still wondering if this is really non-breaking for the project. We could explore that on a feature branch.
Besides removal of deprecated API (like to have) and a required minimal Java version upgrade (not mandatory yet), what else could justify a 2.0 version? Most of the mentioned points should be doable with incremental feature releases.
What about the Web Apps? Someday when the new ones are feature complete with the existing ones, the old ones would be dropped out. Such a removal I would consider as a breaking change, which IMO would need a major version increment, wouldn’t it?
I’m not sure if this is a tendency, yet, so far there are arguments for both solutions and people who prefer one over the other.
Some ideas off the top of my head which require breaking changes:
I think what’s missing in this discussion is how long our main dependencies are supported. If we want to provide a complete OSS stack, we need to support the latest versions of Spring (Boot), Spring Framework, Quarkus and JDK.
The real question is when do we drop support for old versions.
Spring Boot
Spring Boot 3.5 will be OSS supported until June 2026. After that, there is only commercial support until 2032. If we target Operaton 2.0 for end of 2026, Boot 3 is already EOL from an OSS perspective. My opinion: we should not support Boot 3 beyond its OSS window, maybe only for half a year to one year max to give users time to migrate.
spring-boot EOL
Spring Framework
Spring Framework 6.2 (the latest 6.x) has OSS support until June 2026. After that, only commercial support remains until 2032. With Spring Framework 7 coming soon, it makes no sense to hold on to 6.x longer than upstream. Same as Boot: at most half to one year overlap for migration.
spring-framework EOL
Quarkus
Quarkus LTS is supported for 12 months, non-LTS until the next release.
For us this means: do not keep support for Quarkus versions longer than one year after upstream ends.
quarkus-framework EOL
JDK
Spring Framework 7 recommends Java 25 (GA September 2025).
Operaton 2.0 should at least be tested against JDK 25. Baseline could still be 17 or 21, but it must run on 25, since that’s what Spring 7 targets.
eclipse-temurin EOL
jdk/jakarta compatibility
For me:
That way we don’t lock ourselves into maintaining outdated stacks, but we still give users a short, clear migration window.Of course this only works if we have the resources to maintain both tracks in parallel.
Besides the technical reasons, there is also a compliance aspect. Standards like ISO 27001, BSI Grundschutz, OWASP Top 10, and GDPR (§32) require up-to-date and patched software. Outdated frameworks quickly become an audit finding or even a legal risk.
For regulated industries (airlines → IATA, automotive/aviation → TISAX, pharma → GxP, NIS-2 for critical infrastructure) it is clear that we cannot base an OSS project on stacks that are already EOL.
Just a quick thought from my side:
Maintaining LTS branches can become a significant amount of work, and I think we should be careful not to over-promise here, especially until there’s a sponsor willing to cover the effort involved.
Personally, I’d prefer that we stay aligned with the OSS support terms of the upstream projects and do not provide any LTS releases. That way, we can phase out dependencies in a predictable manner and clearly communicate deadlines as soon as we know them.
Also, if someone is specifically looking for an LTS fork of the original C7 (which has still Java EE support and related features), there are already other forks available that they could use.
Just as thought out of the off. As far as I understood the EU Resilience Act, security updates are a must. In JabRef we treat this pretty simple: Always use the latest version. Migrate away of old versions as soon as possible. Sure, we run into trouble with build systems not fast enough supporting the most recent JDK. We only have approx 120 direct dependencies (Link 1)and no SpringBoot depdency. Thus, our case is probably more easy than Operaton.
One could even take part in the OpenJDK Outreach program and get listed at Link 2.
As far as I (superficially) understood the Camunda strategy, it was that open source was always latest greatest and if one wants to have a build, an LTS versions, etc., one needs to pay.
(0 durch o erstzen - Ich darf keine Links posten, deshalb Versuch als Text)
I would like to bring up an issue with existing Camunda plugin structure which could be fixed by changing it. ATM plugin web resources are not found when extracting a spring-boot application into layers. camunda-bpm-spring-boot-starter-webapp: app/plugin.css failed to load · Issue #4718 · camunda/camunda-bpm-platform · GitHub
This would be a breaking change for plugins and therefore a candidate for a 2.0 release.
I don´t know if there are any other issues with the current plugin structure which would benefit from a redesign but some structure decicions (e.g. web apps in early versions) turned out to be non standard so I think they should be revisited.
I don’t think we need LTS branches, if we use the “one module per breaking dependency version” approach.
If a user deploys Operaton with, lets say, Spring Boot 3 and they have an enterprise LTS license for Spring Boot 3, they don’t want Operaton to introduce breaking changes and break the module. They swap the dependency as needed.
But they can migrate in their own time and just use the new module, when they are ready.
In this case we mark old modules as deprecated.
This should also incoroporate the EU Resilience Act. We provide security updates as long as they are officially available and the default migration path for external dependencies.
Another potential 2.0 candidate: Script engines. We have frequently issues with keeping the dependencies for script engines up-to-date. We knew already that we can’t upgrade to JRuby 10, but recently we experienced that we cannot upgrade from 9.1 to 9.2 (or even 9.4).
Tim mentioned that he is thinking about using Truffle for script support. This would be another 2.0 candidate,
I agree that scripting engines are a solid 2.0 candidate, and moving to Truffle/GraalVM makes a lot of sense. We should also tighten up script execution security. Polyglot Context lets us lock down host access, IO, threads, and interop by default. That way we modernize scripting and get a much safer execution model at the same time.