Release r1.1

[yamamoto0104]

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

Create release branch r1.1 for v0.1.0-rc.1 and include CHANGELOG

[eric-murray]

@yamamoto0104
I would suggest to approve and merge #20 before merging this PR so that the alpha version includes the updated error codes

[yamamoto0104]

Hello @eric-murray
I'm fine with your proposal.
we are revieing #20 internally and feedback later.

[yamamoto0104]

Hello @eric-murray
I think 0.1alpha1 can be v0.1alpha1

[eric-murray]

@yamamoto0104

The following still needs to be done before this can be approved and merged:

• Merge Adding API-Readiness-Checklist #18 so that the API readiness checklist is in the release
• Update links in the YAML that reference main to reference the release tag r1.1 instead
  • e.g. link to Number_Recycling_scenario_1.png should be: src="https://raw.githubusercontent.com/camaraproject/NumberRecycling/r1.1/documentation/API_documentation/assets/Number_Recycling_scenario_1.png"
  • Include @camaraproject/release-management_maintainers in the list of reviewers for this PR

[yamamoto0104]

Hello @eric-murray

Thank you for your comments. I updated the link and added @camaraproject/release-management_maintainers.

• Update links in the YAML that reference main to reference the release tag r1.1 instead

  • e.g. link to Number_Recycling_scenario_1.png should be: src="https://raw.githubusercontent.com/camaraproject/NumberRecycling/r1.1/documentation/API_documentation/assets/Number_Recycling_scenario_1.png"
  • Include @camaraproject/release-management_maintainers in the list of reviewers for this PR

@Masa8106 Could you merge #18 ?

• Merge Adding API-Readiness-Checklist #18 so that the API readiness checklist is in the release

[Masa8106]

@yamamoto0104 Yes. I have merged PR#18. Please check it.

[yamamoto0104]

Hello @eric-murray
When I try sync-folk to Release r1.1 branch, the following error occurred. It is probably due to a conflict between the three PRs (#30 , #33 and #38 ) merged earlier (especially the part that removed the 429 error). As a countermeasure, is it better to create a new PR reflecting the corrections in this PR, or to discard it (discard 28 commits)?

[yamamoto0104]

@eric-murray
429 issue was resolved. Other issues are version and x-camara-commonalities.
If we reverted to the original version (verision: wip, x-camara-commonalities.:0.4.0), this conflict error was resolved.

[maxl2287]

Hello @eric-murray When I try sync-folk to Release r1.1 branch, the following error occurred. It is probably due to a conflict between the three PRs (#30 , #33 and #38 ) merged earlier (especially the part that removed the 429 error). As a countermeasure, is it better to create a new PR reflecting the corrections in this PR, or to discard it (discard 28 commits)?

I would just do a merge of the upstream/main into your yamamoto_release_v0.1.0 - branch.

Then you just need to take care to compare your commits with the ones from the main, but let the versions of your branch in it.

[eric-murray]

I fixed the conflict. The following is correct for the release:

  version: 0.1.0-rc.1
  x-camara-commonalities: 0.5

[yamamoto0104]

@eric-murray
Thanks a lot!

[yamamoto0104]

@hdamker and @tanjadegroot
Could you merge this PR into repositories? The following PRs for Commonalities r2.2 and ICM r2.2 have already been merged.

• Remove non mandatory errors following new commonalities #38
• Update x-correlator pattern in number-recycling.yaml #33
• Update ICM authorisation and authentication wording in number-recycling.yaml #30

[hdamker]

@hdamker and @tanjadegroot Could you merge this PR into repositories? The following PRs for Commonalities r2.2 and ICM r2.2 have already been merged.

• Remove non mandatory errors following new commonalities #38
• Update x-correlator pattern in number-recycling.yaml #33
• Update ICM authorisation and authentication wording in number-recycling.yaml #30

@yamamoto0104 The needed steps to merge this PR are as following:

• @tanjadegroot to approve that her requested changes are done
• At least one of your fellow codeowners need to approve as well
• Then merge the PR and directly afterwards create the pre-release in GitHub

[tanjadegroot]

Great progress - ok on these changes.

waiting for the test file to be merged before.

[Masa8106]

LGTM.

[tanjadegroot]

for next time: merge would have needed release management approval first, but I will have a final look, but think it is all fine
so LGTM from Release Management

you should now create the release. @herbert will write the instructions and do the release

[tanjadegroot]

I have check and what has been merges is OK. /LGTM from Release mnagament
@hdamker please helps the team to create the release

[hdamker]

@yamamoto0104 I've created the release already to ensure that the links in your README.md are not going to 404.

For your reference and the next time the steps are:

1. go to "Releases" (right column on repository main page)
2. "create a new release" (or "draft a new release")
3. "Choose a tag": "create new tag r1.1 on publish
4. "Target": main (default)
5. "Title": "r1.1" (release name)
6. "Generate release notes": that's a convenient function to see all PRs which were merged between two releases, but delete "What's changed" section and replace it in next step
7. Copy section for the release out of the CHANGELOG.md (as markdown code), without the headline of the release itself, into the release description
8. Ensure that you correctly selected "pre-release" (or "latest" for public releases)
9. Publish release :-)

[yamamoto0104]

@hdamker Thank you for your instruction.
We submitted PR #40 for r1.2 yesterday, Would it be okay to create release/tag for r1.2? Or should we create them after it has been merged?

@yamamoto0104 I've created the release already to ensure that the links in your README.md are not going to 404.

For your reference and the next time the steps are:

1. go to "Releases" (right column on repository main page)
2. "create a new release" (or "draft a new release")
3. "Choose a tag": "create new tag r1.1 on publish
4. "Target": main (default)
5. "Title": "r1.1" (release name)
6. "Generate release notes": that's a convenient function to see all PRs which were merged between two releases, but delete "What's changed" section and replace it in next step
7. Copy section for the release out of the CHANGELOG.md (as markdown code), without the headline of the release itself, into the release description
8. Ensure that you correctly selected "pre-release" (or "latest" for public releases)
9. Publish release :-)

[hdamker]

We submitted PR #40 for r1.2 yesterday, Would it be okay to create release/tag for r1.2? Or should we create them after it has been merged?

The release tag has to be on the merge commit of the release PR, so you can't create it upfront. I've seen the release PR for r1.2 and create the release review issue for it: camaraproject/ReleaseManagement#179. Please wait there for review comments and/or the approval by Release Management for the PR.

[yamamoto0104]

@hdamker , OK, we'll create the release tag after approval of Release Management team.