Operaton 1.1 and 2.0 are approaching. This makes me wondering if the REST API should be versioned as the Operaton modules itself, or if we need to decouple the versioning of the REST API like we did for the database schema.
From a user’s perspective the REST API is the same in 1.1 and 2.0 as it was in Operaton 1.0. Sure, internal improvements have been made, but from an interface perspective, nothing has changed.
If we would follow semantic versioning for the REST API, the effective API version for 1.1.0 would be 1.0.4. Yes, we released Operaton 1.0.3, and the REST API has at most changed on patch level.
I am wondering if we should put the burden on us to have a separate versioning of the REST API, or simply align with the general version. Latter would be much easier. First would require to establish checks like we have for the Java API with clirr, but for the REST API.
Hi!
I would encourage to give the rest api its own versioning. It gives you the freedom to manage support for multiple api versions within one operaton version: support older versions over several operaton releasees, mark older ones as deprecated, do fixes of a specific api version for more than one operaton version. From a users perspective such api versioning is much more reliable and stable. One can switch to a newer operaton version without the need to upgrade api access, or event think about (nevertheless there will always be breaking changes some time).
Thank you @cwahlmann for your input! It would also be my ideal.
It is a matter of development resources, though. We would need companies funding the additional resources for the release management and building/integration of tools that detect required version updates.