My thoughts about the roadmap

Development
1

I think it would be great if we could keep this fork on par with the C7 releases and I‘m also willing to contribute for this to make this happen.

So our message to the users could be „if you migrate today, you will always get more, never less“.

There could be a version 1.x release train which major goal is to stabilize the fork, create docs/tools and keep everything in a way that Operaton can be used as a 1:1 replacement for C7.

Please also note that during that phase we need to recreate the docs and some missing infrastructure parts (like docker images, CI-CD pipelines, starter project creator, how to handle community projects, migration helper tools, etc). So there is already alot of work to do before we can implement new features.

If we reflect this in the roadmap it would look like this:

Version 1.22 Release in Oct/Nov 2024

  • We integrate all missing commits from 7.22 release and after beta phase this is the first official release. To not confuse user too much we start with version „1.22“ indicating that this release is on par with the 7.22 release

Version 1.23 Release in April 2025

Proposed changes on the c7 roadmap

Changes in Supported Environments:

  • Support for WildFly Application Server 35

  • Support for Amazon Aurora PostgreSQL 16

  • Support for Spring Boot 3.4 (Support is also provided for Camunda 7.22 as a patch)

  • End of Support PostgreSQL 13

  • End of Support WildFly Application Server 23 + 26

  • End of Support Oracle Weblogic 14

  • End of Support PostgreSQL 13

  • End of Support for Spring Boot 3.3

Version 1.24 release in Oct 2025

Proposed changes on the c7 roadmap

Changes in Supported Environments:

  • End of Support Apache Tomcat 9

  • End of Support JBoss EAP 7.4

This version marks the end of development of the 1.x version. We can create a branch here for LTS (if we find contributers for this).

Version 2.0 release (After that with development already starting during 1.x releases)

  • This is the first version as a new fully independent product that may introduce breaking changes

My ideas (or even running patches we have) for breaking changes:

  • Webapps using modern auth and repackaged as standalone web apps. Merge needed missing routes into rest package and remove the web package completely. (This is what we have already patched in our version)

  • Using FEEL in BPMN as expression language

  • Remove all left EE references

  • Reimplement features that are used to be only the EE version (especially some kind of cockpit feature to migrate running processes to newer process versions)

  • Replacing c7 forms with JSONForms

  • Improved api for external workers

  • Improved ways to export and import events/messages from/to systems like Kafka and Jetstream

  • Remove support for most of the application server/frameworks and databases, focus on common configurations like Postgres and Spring. I guess companys using Db2 etc as database will not use the fork anyway. So it does not make sense to maintain a test infrastructure for these configs

  • Cleanup all old migrations, v2 should only able to migrate from 1.24 version. So upgrade path will always be updating to version 1.24 first

What do you think?

1 Like
2

Hi @Julian, thanks for the writeup and sharing your thoughts!

Regarding the version schema: I would prefer following semantic versioning and not coupling our releases to another project. Operaton is a fork of Camunda, but we are standing on our own feet from day 1. Maintaining compatibility to enable users to migrate from Camunda to Operaton is a key issue, but if we follow the versioning schema, it might lead to false impressions. When we plan our own releases, we are free to include bugfixes and patches on our own terms and decide, which of them are minor version releases or patch releases.

The number 1 concern all C7 users would have with Operaton is stability. A Major version release, from 1.0.0 to 2.0.0 signals breaking changes, and most users will migrate to Operaton because they are forced to migrate away from Camunda by breaking changes. They need a reliable tool with minor migration effort, backwards compatibility and a trusted API. When we announce a roadmap which aims at a version 2.0.0, we send the message that there will be major migration efforts ahead in the near future, because we will change the software in such a big way, that it justifies a Major version release.

I like the additions and technical suggestsions in your post, I, too, think that Camunda has been in a maintanence mode with minimal features for a long time and that we should aim to implement new features in the future. But I would advocate for additional features while not breaking backwards compatibility. I think that this is possible for most of the features you are suggesting, if not for all. The new Web Apps are already on our minimal roadmap, maintaining the old ones or porting some of the enterprise features there makes no sense, as long as they are still on Angular.js.

Regarding Application Server and Database support: I agree with you, we should evaluate which of those extensions and supported databases to keep. I’d be interested in how many companies really use Weblogic, Websphere, or some of the databases.

2 Likes
3

Hey @Julian ,

regarding the web apps topic:

Webapps using modern auth and repackaged as standalone web apps. Merge needed missing routes into rest package and remove the web package completely. (This is what we have already patched in our version)

As @javahippie already stated, we inted to rewrite the web apps to move away from AngularJS. Regarding your specific suggestions:

  • Yes, we want to introduce modern authentication
  • Yes, the web app should be able to be deployed standalone. Which isn’t to say we shouldn’t embed it, as we want to have a drop-in replacement and offer users a minimal and easy setup/hosting option
  • Yes, the current web apps custom REST endpoints need to be dealt with. But we intend to, while rewriting the app, only use the ‘official’ endpoints and drop the old apps endpoints entirely
  • Yes, users shouldn’t have to use the old web apps at some point anymore, but I suppose it is better to introduce a configuration option to turn it of – again to keep things compatible

As future prospect: We intend to release some information in the not to distant future about the web apps regarding our progress and detailed goals. With it we hopefully answer all those questions in more detail and open a new thread to get feedback from and engage in further discussions with the community. (which doesn’t mean we want to hold of any discussions on this topic)

1 Like
4

@javahippie As long as backported patches are accepted, the versioning scheme to me personally isn’t that important to me. I was mainly thinking about new users to make migrations easier.

We have to consider this: When migrating from for example C7 7.20 you have to run database migrations.

It’s possible to migrate 7.20 to Operaton 1.0.0-beta-1 by applying the 7.21 & 7.22 db schema migrations. It someones wants to migrate from 7.23 or 7.24 this might be not possible anymore. This must be taken care of and documented how to migrate. These are only very minor db changes in the releases, so it should be doable. Best would be if we are compatible with the 7.24 final db migration script.

1 Like
5

It’s a vaild point. There are existing migration tests in the Camunda Testsuite, which we have temporarily disabled for Operaton, as they started two different Camunda versions and tested the migrations and DB rolling updates. We plan to enable them again asap, so we can make sure that these migrations will also work with Operaton, from several Camunda versions

1 Like
6

@paul we had to move some routes out of the web package like /api/incident, /api/process-definition, /{id}/called-process-definitions, etc. If this of any use i can provide a full list.

These routes were exclusively used by the cockpit but we needed them to be exposed together with the REST api (without the web package even used) because we recreated a frontend for this.

7

Ah, I see now were you were coming from.

Of course we wouldn’t want to break your setup. And it would be likely, that others chose a similar approach.

Two things we need to consider in this situation:

  • Maybe others did the same, but slightly different → how do account for this without creating endless new endpoints.
  • The REST API provides basically the same data, yet has small, but important differences to the web app extension and should be used for all new implementations instead

My suggestion would be the following: creating a modular extension for the REST API which exposes the old web apps endpoints for everyone who still needs it. This should be opt-in: either a config option to turn on or, to keep the main code base clean, something your can extend your installation with. (At this point I would have to refer to @javahippie regarding implementation details of the backend.)
Projects who had a similar setup and need to add some tweaks could fork this extension, and adjust it to their needs.

Does this sound like an option to you?

8

@paul Our preferred way would be to just add the missing parts to the “official” REST Api in a backward compatible way and adjust our frontend (and possible new implementations) to use these routes. The old routes from the web packages can be marked as deprecated and removed when the old angular applications are dropped. For me it doesn’t really make sense that the cockpit apis are not part of the REST Api.

9

Or at least have an option to deploy them without tinkering around with the spring security settings and the deployment of the embedded web applications

10

@javahippie, after giving it more thought, I completely agree with you. Linking the version scheme might create the false impression that this is an “official successor” product. It’s actually a different product that can import data from C7, and we should make sure this distinction is clearly reflected in the roadmap.​