Prepare pre-release r1.1

[eric-murray]

What type of PR is this?

• subproject management

What this PR does / why we need it:

Preparation of release r1.1 for device-identifier v0.2.0-alpha.1

• Update CHANGELOG.med
• Update README.md
• Set versions and url in device-identifier.yaml
• Update API Readiness Checklists

Which issue(s) this PR fixes:

Fixes #71

Special notes for reviewers:

None

Changelog input

 release-note
 - Preparation of release r1.1 for device-identifier v0.2.0-alpha.1

Additional documentation

N/A

[hdamker]

Please add @camaraproject/release-management_maintainers when ready for review.

Regarding the release number: I also learned only recently that the release numbers are not tied to the meta-release, but start always for an API repository with r1.1, c.f. https://github.com/camaraproject/ReleaseManagement/blob/main/documentation/API_Release_Guidelines.md:

The release numbers shall follow the guidelines described below.

• Release numbers start with x=1 and y=1: r1.1.
• y is incremented by 1 at each subsequent alpha, release-candidate and public release, and for a maintenance release, e.g. rx.y+1.
• After a meta-release of an API through release rx.y, the next release number for this API is rx+1.1 (y resets to 1).
• In case of maintenance of a release rx.y, the new public release shall be rx.y+1.

Given that the release number should be r1.1 - @tanjadegroot correct?

[eric-murray]

All references to r2.1 changed to r1.1

Changes made as requested

[hdamker]

Lines 124/125 (contact field) should not be included.

[hdamker]

One minor, but important c&p mistake to be corrected

[hdamker]

I've created a release tracker within the wiki. Please check: https://lf-camaraproject.atlassian.net/wiki/x/cABkAQ (especially if you plan to go with 0.2.0 into the Spring25 meta-release, or only with the next initial release).

[eric-murray]

One minor, but important c&p mistake to be corrected

Thanks @hdamker. Thought I'd caught them all.

Re-adding @camaraproject/release-management_maintainers should anybody else want to review.

[hdamker]

@eric-murray There were no further comments within today's Release Management call. So you are good to go as soon as @Kevsy has approved.

Just the release tracker needs to be replaced as we today in RM changed the template again a little bit. I can take that as soon as the template is updated (as the last step of the release review).

[hdamker]

@eric-murray @Kevsy PR is ready to get merged and release created.

And: I have recreated the release tracker based on the latest template updates. Can you please check and decide if 0.2.0 is the target version for Spring25 or do you plan the public release earlier and a later version for Spring25? Depending on that please update the first line of the release tracker and the label on the page: https://lf-camaraproject.atlassian.net/wiki/x/boNkAQ

[tanjadegroot]

Please add @camaraproject/release-management_maintainers when ready for review.

Regarding the release number: I also learned only recently that the release numbers are not tied to the meta-release, but start always for an API repository with r1.1, c.f. https://github.com/camaraproject/ReleaseManagement/blob/main/documentation/API_Release_Guidelines.md:

The release numbers shall follow the guidelines described below.

• Release numbers start with x=1 and y=1: r1.1.
• y is incremented by 1 at each subsequent alpha, release-candidate and public release, and for a maintenance release, e.g. rx.y+1.
• After a meta-release of an API through release rx.y, the next release number for this API is rx+1.1 (y resets to 1).
• In case of maintenance of a release rx.y, the new public release shall be rx.y+1.

Given that the release number should be r1.1 - @tanjadegroot correct?

Yes, correct

[tanjadegroot]

Line 32 should be a relative link (no reference to "main")

[hdamker]

Line 32 should be a relative link (no reference to "main")

That wouldn't work if the YAML is used outside the GitHub context, e.g. in swagger editor. Instead the main has to be replaced with the release. But I wouldn't do that for alpha releases, here it don't matter if the picture get updated until the release candidate.