Prepare maintenance release r2.3

[fernandopradocabrillo]

Update CHANGELOG.md, README.md and API Readiness Checklist to reflect the new maintenance release tag r2.3, which fixes test scenario error codes and typos compared to r2.2.

What type of PR is this?

• subproject management

What this PR does / why we need it:

Prepares the maintenance release r2.3 by updating all release version references from r2.2 to r2.3. The API definition (device-swap v0.2.0) is unchanged; this release contains only test definition fixes introduced in PR #87.

Which issue(s) this PR fixes:

Fixes #84

Special notes for reviewers:

The API YAML spec is not modified. The only functional changes in this release line are in the test feature files (already merged via PR #87): error code NOT_SUPPORTED corrected to SERVICE_NOT_APPLICABLE and several typos fixed in scenario descriptions.

Changelog input

[fernandopradocabrillo]

Hi @hdamker! this one is for the maintenance release, I hope I covered everything, it's been a while since the last one I did 😄 if something is missing we can blame claude 👀

[hdamker]

I would recommend to change the API version to 0.2.1:

• to indicate the patch ... currently the CHANGELOG reads odd, same version but changes
• as the test definition is part of the API contract (defining the behavior) and at least implementors need to be aware that there were changes. If they see exactly the same version they would not expect any changes
• the version is also used in the test definition files and should be not the same as in r2.2 (Feature: CAMARA Device Swap API, 0.2.0 - Operation checkDeviceSwap)

The server URL will be unchanged (v0.2), so clients are not impacted as long as the changes in test definition changes do not imply a client visible behavior change.

[bigludo7]

LGTM

[fernandopradocabrillo]

Hi @hdamker, sorry for the late response. I don't think we should increase the api version since no change in the functionality has been done. I don't agree with the test plan being part of the api contract, I understand it as part of the documentation. I don't really see a problem in having the same api version in different releases since we don't have any other mechanism to reflect changes in the documentation other than the releases.

Thanks!

[hdamker]

I don't agree that this can stay at 0.2.0.

• A maintenance release is defined as "a patch update of a public API version" — one with no version change isn't a case the process covers.
• The test plan is part of the documented API, not outside the contract: SemVer §1 says the public API "could be declared in the code itself or exist strictly in documentation," and CAMARA already scopes it that way — every Feature: line carries the API version, checked by the Validation Framework. r2.2 and this release both say 0.2.0 - Operation checkDeviceSwap over different scenario content; that label should identify one test plan for one version, not two. A documentation change with no functional/behavioral change is exactly the case SemVer §6 defines a patch bump for ("backward compatible bug fixes") — not a reason to skip one.

Suggest: version: 0.2.1 in device-swap.yaml (server URL stays v0.2), carried into the Feature: lines and this CHANGELOG entry.

[hdamker]

Two small copy-paste leftovers in the new CHANGELOG.md section, independent of the version discussion above — worth fixing either way since this is a maintenance release, not a public release:

• "This public release contains the definition and documentation of" → "This maintenance release contains..."
• "device-swap v0.2.0 is the public release of the Device Swap API" → this line was accurate for r2.2; here it should reflect that r2.3 is the maintenance release of that version.