fix: x-camara-commonalities to use full version string

[hdamker]

What type of PR is this?

• correction

What this PR does / why we need it:

Updates the x-camara-commonalities extension field to use the full version string (e.g. 0.7.0 or 0.7.0-rc.1) instead of just the minor version (e.g. "0.7").

With the introduction of release automation (tooling#119), this field is set automatically using the version from VERSION.yaml at the Commonalities release tag. The original restriction to minor-only was motivated by manual maintenance effort, which no longer applies.

Changes:

• API Design Guide (section 5.3.7): updated guideline text and example to use full version string
• CAMARA_common.yaml: "0.7" → 0.7.0
• event-subscription-template.yaml: "0.7" → 0.7.0

Which issue(s) this PR fixes:

Fixes #598

Does this PR introduce a breaking change?

• Yes
• No

Special notes for reviewers:

The release automation tooling already writes the full version string. This PR aligns the guideline and artifacts with the automated behavior.

Changelog input

 release-note
x-camara-commonalities extension field now uses full version string (e.g. 0.7.0) instead of minor-only (e.g. 0.7)

Additional documentation

docs
Updated section 5.3.7 of CAMARA-API-Design-Guide.md

[patrice-conil]

LGTM

[PedroDiez]

@hdamker one doubt, intention is to use this model since Signal26, isn't?

[Kevsy]

LGTM, but a related question: should there be a schema definition for `x-commonalities-version' ? The Open API Specification has no constraints for the extension value datatype, but should we (e.g. a regex?)

[hdamker]

LGTM, but a related question: should there be a schema definition for `x-commonalities-version' ? The Open API Specification has no constraints for the extension value datatype, but should we (e.g. a regex?)

@Kevsy Good question. Since this is purely a static metadata field (never part of API requests/responses), a schema wouldn't really add value. The format is already defined by convention — it's the version string from VERSION.yaml at the Commonalities release tag, so it follows semver. And our tooling already ensures it programmatically, which can do more than a regex (e.g., checking it matches the actual Commonalities release used).

[hdamker]

@hdamker one doubt, intention is to use this model since Signal26, isn't?

@PedroDiez Yes, the intention is to apply this from Spring26 (not renamed to Signal26 btw) onwards. The release automation will set this field automatically using the version from VERSION.yaml at the Commonalities release tag.

[PedroDiez]

LGTM