ICM patch release r0.2.1

[jpengar]

What type of PR is this?

• subproject management

What this PR does / why we need it:

This PR is to update the README and CHANGELOG files for the r0.2.1 patch release. This patch release fixes broken W3C Data Privacy Vocabulary (DPV) reference links in the ICM documentation.
The original idea was to create a maintenance release (and maintenance branch) where this needed fix would be applied. However, there are still some pending discussions about maintenance releases in the Release Management Working Group, and as a short-term solution it was suggested by @hdamker (#196 (comment)) to create a patch release in the main branch.

Which issue(s) this PR fixes:

N/A (It is related to Issue #195 and the fix applied in PR #196)

Special notes for reviewers:

See #196 for further context.

Changelog input

 ICM patch release r0.2.1

Additional documentation

camaraproject/ReleaseManagement#93

[tanjadegroot]

as I put here as well (#196 (comment)):

For maintenance releases of APIs, the process is described here: https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14559630/API+Release+Process#PATCH-update.

We could add something similar to the Comm/ICM process part (with the exception that it would use the version number iso the release nr for Fall24 patches.).

So the process would mean to have a branch called "maintenance-020" of the 0.2.0 release in which the above changes will be applied.
On that branch you would then have the patch releases of 0.2.1, 0.2.2, or r1.3 if we consider the current release did r1.1 (RC) and r1.2 (currrent public) applying the release numbering to Comm/ICM as well. In that case the patch should include the version file in the main directory VERSION.MD with inside the text "icm-version: 0.2.1" for this first patch.

for me these changes can either

1. go in and later changes could be done a additional maintenance-releases on this branch as needed,
2. or be released later

but as this fixed broken links etc, I would consider option 1 is best.

Each patch that is released, if no impact on API implementation can also be merged into main immediately IMHO.

/LGTM from Release Management

[hdamker]

@tanjadegroot

For maintenance releases of APIs, the process is described here: https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14559630/API+Release+Process#PATCH-update.

I'm not sure that this part of the release management processes was already reviewed in detail. I have added some comments there. Especially I don't see why we need to create already a maintenance branch if there were no other changes in main since the Meta-release public release.

We could add something similar to the Comm/ICM process part (with the exception that it would use the version number iso the release nr for Fall24 patches.).

So the process would mean to have a branch called "maintenance-020" of the 0.2.0 release in which the above changes will be applied. On that branch you would then have the patch releases of 0.2.1, 0.2.2, or r1.3 if we consider the current release did r1.1 (RC) and r1.2 (currrent public) applying the release numbering to Comm/ICM as well. In that case the patch should include the version file in the main directory VERSION.MD with inside the text "icm-version: 0.2.1" for this first patch.

I wouldn't do the change of release numbering now in context of the Fall24 release ... we can't change the existing releases, so I would propose to start the new numbering only with the Spring25

...

/LGTM from Release Management

For this Patch and the PR same from my perspective: /LGTM

[jpengar]

@tanjadegroot @hdamker If you don't mind, I will merge this PR and generate the new patch release as suggested as a short-term solution. And then for future changes (hopefully not needed for this release) we can follow whatever procedure we end up agreeing on in the Release Management WG.
CC @AxelNennker @sebdewet I need a code owner review and approval to do this.

P.D: I will be OOO from today until 08/10, if I can't merge this PR today, I need you guys to do it in my absence. And then create the release and relase tag and update the RM confluence Fall24 page with the new patch release info.

[tanjadegroot]

@jpengar OK for the short terms solution LGTM

[tanjadegroot]

@hdamker

For maintenance releases of APIs, the process is described here: https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14559630/API+Release+Process#PATCH-update.

I'm not sure that this part of the release management processes was already reviewed in detail. I have added some comments there.

true, not actively, we are improving the text as we learn.

Especially I don't see why we need to create already a maintenance branch if there were no other changes in main since the Meta-release public release.

IMHO the maintenance release branch approach should be the standard process, but if you want to skip it this first time, it is OK but as an exception.

We could add something similar to the Comm/ICM process part (with the exception that it would use the version number iso the release nr for Fall24 patches.).

So the process would mean to have a branch called "maintenance-020" of the 0.2.0 release in which the above changes will be applied. On that branch you would then have the patch releases of 0.2.1, 0.2.2, or r1.3 if we consider the current release did r1.1 (RC) and r1.2 (currrent public) applying the release numbering to Comm/ICM as well. In that case the patch should include the version file in the main directory VERSION.MD with inside the text "icm-version: 0.2.1" for this first patch.

I wouldn't do the change of release numbering now in context of the Fall24 release ... we can't change the existing releases, so I would propose to start the new numbering only with the Spring25

OK, agree

[hdamker]

LGTM from perspective of release management and can be merged, and the release created.

[diegogonmar]

@AxelNennker @sebdewet, as Jesús is on holiday, can you proceed with merge? And then create the release and release tag and update the RM confluence Fall24 page with the new patch release info.? Thanks!