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!