Fix W3C DPV broken links in ICM doc

[jpengar]

What type of PR is this?

• correction
• documentation

What this PR does / why we need it:

W3C Data Privacy Vocabulary (DPV) reference links in ICM documentation are broken. This PR fixes the broken links in the required documents.

Which issue(s) this PR fixes:

Fixes #195

Special notes for reviewers:

N/A

Changelog input

Fix W3C Data Privacy Vocabulary (DPV) broken reference links

Additional documentation

N/A

[AxelNennker]

@camaraproject/release-management_maintainers should we put this into the meta release?
@hdamker

[hdamker]

My view would be to start to work on a Maintenance Release r0.2.1 which includes this and maybe other fixes which will come up. If the APIs are not impacted directly (in sense: they need to adapt something) and the corrections have some value for the audience, I would be in favour of such release with a patch version.

And it is foreseen with Release Management - within the API_Release_Guidelines there is the following description:

Maintenance release

In case a patch update of a public API version x.y.z is required, the patched public API version x.y.z+1 shall be created through a maintenance release on a separate branch referred to as a maintenance branch.

NOTE: a patch is the only case for which a separate branch is created and maintained within the API repository (as pull requests should be prepared within forks of the API repository, c.f. Governance/CONTRIBUTING.md)

The reasoning ist that the main branch should not be blocked by the Maintenance Release(s) of the Fall24 version. But as long you haven't done anything within the main branch you can do the updates also there and create the Maintenance Release (or doing it vice versa: merging the Maintenance branch also into main afterwards).

[hdamker]

BTW: You may want to clean up the 16 branches which are left from previous PRs - normally that can be done already safely when the PR is merged.

[jpengar]

BTW: You may want to clean up the 16 branches which are left from previous PRs - normally that can be done already safely when the PR is merged.

You're right. Done. Thanks for the warning. https://github.com/camaraproject/IdentityAndConsentManagement/branches

[jpengar]

@hdamker @camaraproject/release-management_maintainers Would it then be okay to merge this PR into main (we haven't made any changes to main since the r0.2.0 public release), and then create the maintenance release branch from main?

Should I call this maintenance branch r0.2.1? r0.2.1-maintenance? Is there any naming convention for this?

Then we can wait a reasonable amount of time, in case other fixes are needed, before creating the tag and the actual maintenance release r0.2.1 on github.

CC @AxelNennker @sebdewet

[hdamker]

@jpengar

Would it then be okay to merge this PR into main (we haven't made any changes to main since the r0.2.0 public release), and then create the maintenance release branch from main?

Sure, makes sense.

Should I call this maintenance branch r0.2.1? r0.2.1-maintenance? Is there any naming convention for this?

There is no naming convention yet, maybe we should put it on the agenda for the next Release Management call (on Tuesday, Sept 2nd - but I will most probably miss that call).

r0.2.1 would conflict with the tag ... you can't create the tag if there is already a branch with the same name. I would keep the branch name also independent of the patch number, e.g. maintenance-r0.2 ... then it can stay. I also think that then the branch prefix maintenance* should be protected like main.

[jpengar]

We can wait for feedback from Release Management, I see no problem with that. For me, it looks good to merge this PR into main, and then create a new branch maintenance-r0.2 from main.

[jpengar]

@hdamker @camaraproject/release-management_maintainers Did you manage to review this topic about the maintenance releases?

[hdamker]

@hdamker @camaraproject/release-management_maintainers Did you manage to review this topic about the maintenance releases?

I wasn't in the last Release Management meeting, but guess that don't. I have created now camaraproject/ReleaseManagement#93 for that.

[hdamker]

@hdamker @camaraproject/release-management_maintainers Did you manage to review this topic about the maintenance releases?

@jpengar as a short-term solution: as long as there is no other PR for a later version merged into main you can just create the patch release on main itself.

[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.

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.)