Stable release of Commonalities for Spring26

[rartych]

With the discussed changes in meta-release strategy and quite advanced status of API guidelines the stable release (i.e v1.0.0) should be considered for Spring26 (some APIs are already published in stable versions).
After producing stable release of Commonalities any breaking change should lead to increasing major version number.

On the other hand we should justify if all Commonalities documents can reach stable status for the next release.
If it can not be expected then we should consider other way of versioning - for example separately for each document.

Please provide your thoughts, ideas or examples of good practices for that subject.

[hdamker]

My thought is that the different documents and artifacts should have their own version numbers, which then will be listed also within the release notes. Currently we have a 1:1 bound between release tag and the version in VERSION.yaml.

Decoupling that will allow:

• to declare the documents independently of each other as stable (e.g. API Design Guide 1.0.0, while CAMARA-API-Event-Subscription-and-Notification-Guide.md might still have a 0.x version)
• to indicate within a release which artifacts have been actually updated (and if this update was a patch, minor or major update). That will especially helpful for patch releases

BTW: CAMARA_common.yaml has already today an own version number, which is kind of confusing (and not listed within the CHANGELOG.md for the releases).

[PedroDiez]

Think that makes sense to have first stable version for Commonalities.
Topics related to Subscriptions (e.g. Issue 556) and Linting would be relevant to be covered for this first stable version