Operaton 1.0 is almost here, and (potential) users are asking for a release cadence. The discussion started in the Slack channel, but should be continued here.
The first ideas are
feature releases could be scheduled, bugfixes and security fixes as soon as we find issues
feature releases could be quarterly, or half-yearly
quarterly would imply Operaton 1.1 to be delivered in Feb '26
fast security update releases require development resources that are available to perform merging, testing and releasing. The project must akquire more development power to ensure these deliveries
vulnerability scanners have to be active on all docker images and maven artifacts
once decided, the roadmap and FAQ have to be updated
Please provide your input to shape the future release schedule.
I agree with most of your points. Quarterly feature releases sound good to me, and we already have a backlog with ideas for them. There will be some small adjustments and additions, and it will further help to improve our (already very good) release process.
Bugfixes and Security fixes as a patch release as soon as we need them also sounds like a sensible thing. This is also important to users in an enterprise setting. We can commit, that we can contribute, test and release issues that arise from our service contracts with priority, but of course this also requires additional input and effort from the maintainers. What we can not do is promise a certain reaction time as the Operaton project. If a service company promises certain reaction times to their customers, they need to be able to contribute the fixes to the project in that timeframe, they cannot rely on the maintainers for this.
On our Docker Repo, we already have capacity for 2 artefacts under a vulnerability scan. I need to check how to extend this to all 3 artefacts (how much this will cost) and if we can get automated notifications for this. Locally, I am currently checking the images with trivy from time to time, this could also be run in a GitHub action and would work in a more transparent way. Trivy can also do this on the source code and the dependencies, but I’m not sure if this is an improvement over the GitHub Security processes.
I would second the approach of scheduled feature- and on-demand patch releases. Quarterly feature releases seem to be quite ambitious, I think half-yearly is more practical. Another reason is database compatibility: the last two minors versions should be able to run on the same db in order to support a rolling update. To support patch releases we must follow a strict policy - no feature back ports, just patch updates of dependencies or critical bug fixes.
One change to the current (Camunda) regime could be to support a minor version for 12 month instead of just 6. This would give organizations more flexibility to schedule theirs upgrades.
scheduled feature release (half-yearly)
support timeline: 12 month
db compatibility: 2 minors versions
on-demand or scheduled patch releases for supported minor versions
On-demand patch releases might be too optimistic. In a project with so many external dependencies, security scanners will almost definitely report issues after a few weeks. Wdyt?
Sounds good to me. Could be that quarterly is too fast for feature releases. We need to deliver patch releases faster. I think we all agree here.
Would users accept half-yearly feature releases to choose Operaton? We need feedback, and we need users.
We should agree on something realistic and shape the road map with it. So next feature release in 6 months?
DB compatibility for 2 minors / 1 year can be challenging,
On-demand patch releases should be possible quite fast. We need to optimize the release process a bit. The more often we do this, the better we become.
I am looking forward a face-to-face discussion on all these topics at the Release Party.
I have talked with @javahippie and we think that the first feature release could be after ~3 months. There does not need to be many features in it, nor a DB schema change. Larger features can be prepared on feature branches that do not make it to main and the next feature release until we are sure they can make it. Spring 7 support could be one for the next release, for example. Means, we could try to start with 3 months, and stay with the DB schema 7.24. I also think we should decouple the DB versioning from the main version. A DB version change is only required when actually something is changing. In C7, there was a direct coupling, which made sense for that. For the future, we would only introduce new DB scripts when actual changes are made.
We have to come up with a release date for version 1.1. I propose version 1.1 for 27th Feb 2026.
I would like to contribute my thoughts on the subject. Because I think that we are once again forgetting that we are not a company and that everyone here does everything in their spare time.
Companies can offer fixed release cycles because they have teams working on the projects. My suggestion is that we start with a relaxed and simple release strategy and see how things develop. This is especially important if there is a phase where we don’t have as much time or there aren’t as many ideas, and we may not be able to keep to a planned release.
On the Postgres site, I found an idea that I think is quite good: PostgreSQL: Roadmap This only concerns minor releases.
If you want to announce regular releases, then at least every 6 months, if not at longer intervals.
Security patches as fast as we can deliver.
We also have to remember to protect our contributors.
The PostgreSQL project aims to make at least one minor release every quarter, on a predefined schedule.
This is what I proposed actually. I know that we cannot guarantee certain features, but we can make releases plannable. We have to be aware that a project like Operaton has to predict rough release dates in order to make it for users plannable when they schedule upgrades.
I do think we should agree on a date, or just month when we aim to release the next minor release. It is an important message that we have to send now to potential adopters. Especially, there will be adopters that will wait for a 1.1 version to start an evaluation. With a version 1.1 we will not ship major features, nor DB schema changes, if we can avoid that.
But the discussion is also about a cadence. 3 months sound ambitious, but it is also a long time. Also on our main branch, there have already been plenty changes. Granted, mostly refactorings and dependency updates.
For larger features that need to mature, developing them on feature branches until they are ready is a doable approach. Like the new web apps. And when we finally decide that it is ready enough to go for the next release, the feature should be integrated at the beginning of a release cycle, or in other words, soon after a release. Then it is time enough to get feedback and stabilize.
We need to gain trust for conservative people. And what they need is a plan. Of course, we need to work together that the plan holds. If we miss it slightly at the beginning, that’s not crucial. We just have to become better and better.