Release PR for public release r1.2 (M4)

[maheshc01]

What type of PR is this?

Add one of the following kinds:

• documentation
• subproject management

What this PR does / why we need it:

Issues #95 and #97

Which issue(s) this PR fixes:

Fixes #95 and #97

Special notes for reviewers:

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.03s
✅ OPENAPI	spectral	3		0	4.79s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	0.7s
✅ YAML	yamllint	3		0	0.67s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[Kevsy]

Looks good except for a few occurrences of the 'rc.1' suffix to remove.

[Kevsy]

^ just those minor tweaks above otherwise LGTM @maheshc01

[hdamker]

@maheshc01 @Kevsy according to the release numbering this is r1.2, not r1.1 (and you have already correctly the tag r1.1). If it make sense to keep the releases notes of r1.1 within the CHANGELOG might be an open topic, but currently the guidelines say that the new release is just added on the top, leaving the history unchanged.

[rartych]

API versioning was decoupled from release numbering:
https://wiki.camaraproject.org/display/CAM/API+versioning
https://wiki.camaraproject.org/display/CAM/API+Release+Process#APIReleaseProcess-APIreleasenumbering
So after r1.1-rc.1 we should have r1.2 and the APIs should have initial public version (0.y.z)
The example of changes for M4 and the CHANGELOG structure for QoD: camaraproject/QualityOnDemand#353

[maheshc01]

@maheshc01 @Kevsy according to the release numbering this is r1.2, not r1.1 (and you have already correctly the tag r1.1). If it make sense to keep the releases notes of r1.1 within the CHANGELOG might be an open topic, but currently the guidelines say that the new release is just added on the top, leaving the history unchanged.

@hdamker
updates to CHANGELOG is what is not clear to me.
I am trying to refer other CAMARA APIs but still doesnt help. for example full changelog currently points to 1.1. Would that be just replaced with 1.2 and the content of the full change log needs to be same as 1.1?

[hdamker]

updates to CHANGELOG is what is not clear to me.
I am trying to refer other CAMARA APIs but still doesnt help. for example full changelog currently points to 1.1. Would that be just replaced with 1.2 and the content of the full change log needs to be same as 1.1?

@maheshc01 In this special situation (only one pre-release, no previous public release to compare with) I have full understanding for the confusion. Yes, r1.2 would more or less repeat the changes from r1.1. But you might want to select and reformulate for a different audience: while the pre-release was (theoretically) for implementors, the public release has now also API Customers as audience.

An example which which shows r1.1 and r1.2 in the CHANGELOG.md and also that r1.2 could be a selection out of r1.1 changes: camaraproject/HomeDevicesQoD#70

[maheshc01]

updates to CHANGELOG is what is not clear to me.
I am trying to refer other CAMARA APIs but still doesnt help. for example full changelog currently points to 1.1. Would that be just replaced with 1.2 and the content of the full change log needs to be same as 1.1?

@maheshc01 In this special situation (only one pre-release, no previous public release to compare with) I have full understanding for the confusion. Yes, r1.2 would more or less repeat the changes from r1.1. But you might want to select and reformulate for a different audience: while the pre-release was (theoretically) for implementors, the public release has now also API Customers as audience.

An example which which shows r1.1 and r1.2 in the CHANGELOG.md and also that r1.2 could be a selection out of r1.1 changes: camaraproject/HomeDevicesQoD#70

have made the updates to use release r1.2.
in the changelog i have made the information on individual APIs look more concise to avoid repeating the same text twice. Hope that looks ok.
@hdamker please review and let me know if i have missed anything or further changes are required.

[maheshc01]

Hi @rartych,
I have committed changes to apply the fixes based on your review comments.
both the changes are related to updates made to changelog as follows:

1. revert the content that was part of r1.1 to keep the history of the file unchanged and only add updates related to r1.2
2. naming convention for the APIs followed as per the release mgmt guidelines.

requesting for your review.

[rartych]

Contact field in Camara specifications does not include valuable information.
It was decided to remove optional fields from info object:
https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#info-object

I suggest to remove contact from info object in all yaml files

[hdamker]

have made the updates to use release r1.2.
in the changelog i have made the information on individual APIs look more concise to avoid repeating the same text twice. Hope that looks ok.
@hdamker please review and let me know if i have missed anything or further changes are required.

@maheshc01 Consider the release notes for r1.2 as completely independent from the previous content of the CHANGELOG, listing all changes since the last public release. An API user who is relying on the latest public release should not be forced to read the pre-release notes. (see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md#v1300 for an - extreme - example).

We copy currently exactly this part into the release description of GitHub.

I suggest that the release notes for r1.2 in your case should at least mention that this is the first public release of these APIs (which is not obvious as the version numbers are already 0.3.0 or 0.4.0) - to justify why there are no changes mentioned in the release notes. If previous versions where published somewhere else then maybe a reference might make sense and then listing the changes for those who know the previous APIs. Many of the changes happened all in one PR, so the format used by other APIs (one change more or less equal one PR) won't work here.

[maheshc01]

have made the updates to use release r1.2.
in the changelog i have made the information on individual APIs look more concise to avoid repeating the same text twice. Hope that looks ok.
@hdamker please review and let me know if i have missed anything or further changes are required.

@maheshc01 Consider the release notes for r1.2 as completely independent from the previous content of the CHANGELOG, listing all changes since the last public release. An API user who is relying on the latest public release should not be forced to read the pre-release notes. (see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md#v1300 for an - extreme - example).

We copy currently exactly this part into the release description of GitHub.

I suggest that the release notes for r1.2 in your case should at least mention that this is the first public release of these APIs (which is not obvious as the version numbers are already 0.3.0 or 0.4.0) - to justify why there are no changes mentioned in the release notes. If previous versions where published somewhere else then maybe a reference might make sense and then listing the changes for those who know the previous APIs. Many of the changes happened all in one PR, so the format used by other APIs (one change more or less equal one PR) won't work here.

Hi @hdamker

based on your review comments i have made 2 updates to the README

1. reworded to highlight that this is the first public release

• r1.2 is the first public release of connectivity insights with the following API definitions:

2. removed the link to changelog and added below note clarifying that this being the first public release, change log is not applicable

• Note: This being the first public release of the API, list of changes as compared to previous public release is not applicable and hence not provided.

[rartych]

LGTM

[hdamker]

• Note: This being the first public release of the API, list of changes as compared to previous public release is not applicable and hence not provided.

Fine for me. But the line from the template (look for line 32 in the code) with the link to CHANGELOG.md wouldn't do any harm, as the CHANGELOG.md has some change information about r1.1, could stay unchanged within next releases and would be more consistent across the READMEs (I'm not aware of other APIs who have your note, but haven't checked this explicitly).

[hdamker]

LGTM, previous two comments are optional.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: maheshc01 / name: Mahesh (45b483f, 4d6d9df, 4bcc2c6, 3d1d0a3, ab0ba64, 2736add, 3180b68, e6ddf62, 8af3207, bf39a2a)
• ✅ login: hdamker / name: Herbert Damker (e46f07b)

[hdamker]

@maheshc01 Looking on https://patch-diff.githubusercontent.com/raw/camaraproject/ConnectivityInsights/pull/98.patch it seems that the commits which can't be checked by EasyCLA are done with [email protected] while the successful check ones are done with [email protected]. Maybe adding the first address to your GitHub account will solve the issue and unblock the PR to be merged?

[maheshc01]

@maheshc01 Looking on https://patch-diff.githubusercontent.com/raw/camaraproject/ConnectivityInsights/pull/98.patch it seems that the commits which can't be checked by EasyCLA are done with [email protected] while the successful check ones are done with [email protected]. Maybe adding the first address to your GitHub account will solve the issue and unblock the PR to be merged?

Hi @hdamker ,
I already have [email protected] as my primary email address on github account.
I will be reaching out to Casey today to see if he can help me with this.

Meanwhile would you know if there is any way to proceed on this?
@Kevsy can you check if you can make any update to move this forward.

Thanks,
Mahesh. C

[hdamker]

@maheshc01 @Kevsy I've tried a small change (you can revert it if you like) with e46f07b to trigger a new check. Check is updated, but still not happy - maybe past commits can't be claimed by setting the email within GitHub.
@maheshc01 what you can try if not yet done: deactivate the "Keep my email addresses private" options within the GitHub Settings -> Emails. Could be that this prevents the match (if you want to keep it private you need going forward to use also in git the private address from GitHub, in your case [email protected]).

Beyond that I have recognised that the branch is one (merge) commit behind main. Something worth to correct before starting other options (like downloading the files and upload them in another, new branch as new commits).

the 3 review comments shared are accepted and committed. individual changes show as resolved but the parent comment is still unresolved incorrectly. Hence dismissing the review as this status is incorrect.

[maheshc01]

I was able to work with Casey to resolve the easy cla related issue for the commit. have also ensured the branch is updated with the latest code from main.
Do I have a go ahead to merge? @hdamker @rartych
@Kevsy you might still have to approve the changes.

[maheshc01]

thanks for the quick actions. I see that i have all the approvals on this.
Should i still wait for an explicit go ahead for the merge approval or am i good to go ahead and merge the code.
Please confirm @rartych @hdamker .