We need to make a decision about the database version in the next few days. This is becoming a blocker for backports, and resolving it quickly will help us move forward. I don’t have a strong preference myself, so I’d love to hear your thoughts on this! For context, here’s the relevant PR: #309.
Key points raised so far:
Keep C7 database version scheme
This would not allow us to do our own database schema changes.
Raising to version 8.0
As it would reflect a major change and align with the idea of evolution from 7.x.
Syncing Versions with the Main Project
A clean break and fresh start might make the transition clearer. It avoids inheriting legacy connotations of previous version numbers. This approach ensures consistency and avoids confusion for users migrating between versions.
Potential issue: Users coming from 7.23/7.24 may need to skip some SQL statements. These could be marked with comments in the SQL files for clarity.
Documentation is Key
No matter the approach, clear documentation will be essential.
My Take:
I tend to agree that syncing the version with the main project might be the most straightforward solution, provided it’s feasible. But I’m also open to exploring other suggestions.
Let’s use this thread to gather input and come to a consensus!
What do you think is the best path forward?
Would love to hear everyone’s perspective on this.
As far as I see, Liquibase is using the default run order, meaning the changesets are applied in the order they have in the XML. In this case, the versioning scheme is secondary, as it does not carry any semantics.
If we made any changes to the database while Camunda is still being actively developed, we would risk breaking our migrations. E.g. if we now create a changeset, then all upcoming Camunda changesets will be applied afterwards.
If a user waited until 7.24 to migrate to Operaton, Liquibase would detect that a changeset was present in the XML, but not yet applied to the database and fail.
In this case I would refrain from making changes to the database until 7.24 is final, Camunda is EOL and then increase the version according to the schema. In this case, our next version would be 7.25. The database versions would then be detached from the product version, but that would be fine with me. 8.0 would imply a breaking change. 1.0 would confuse readers of the changelog in the future.
That would of course mean we cannot do our own db changes until Oct 2025. And if we decide to do our own changes we have created a mess with the versions, having an incomplete 7.23 version changelog, etc
But this is true no matter how we decide on the version, no? That’s a big “issue” with tools like Flyway and Liquibase, the migrations have to be applied in the same sequence, else the database might become unstable. I don’t see a critical usecase which makes us add new database tables urgently, waiting until 7.24 might be the safest bet
ok i would then propose for now we change the database version to 7.23. we can re-evaluate the situation in April 2025 when database version is changed to 7.24
My two cents: It would be sensible to keep the full Camunda compatibility as long as possible, both on the code and the DB level. Camunda compatibility and the promise to its current users that they will have a supported compatible product once C7 is discontinued is the main feature of operaton IMO. It’s more important than some possible new cool features, and it would be pity to lose it early.
