Call Forwarding Signal release as a part of CAMARA Meta-release

[rartych]

Meta-release process is defined by Release Management https://wiki.camaraproject.org/display/CAM/Meta-release+Process
Currently the process for Meta-release Fall24 has started: https://wiki.camaraproject.org/display/CAM/Meta-release+Fall24

The following are the actions for milestones:

M1

• Create API release tracking page for the API if it does not yet exist
• Create API release tracker for the API version to be released
• Assess final impact of final release-candidates of Commonalities and ICM scope on API(s)
• Define scope of API release:
  • Record scope in dedicated GitHub issue.
  • Update the release tracker with the scope issue link
• Develop API scope through one or more alpha releases
• Update the API release tracker with each alpha release
• Create first release-candidate PR and submit to Release Management
• After Release Management approval:
  • Create first release-candidate for the API
  • Update the API release tracker with the release-candidate tag

M3

• Fix bugs raised by API testers through one or more release-candidates
• Update API release tracker with each release-candidate
• Submit final release-candidate PR to Release Management for checking
• After final release-candidate PR approval by Release Management:
  • Create final release-candidate and update API release tracker
  • Create API public-release PR
• After TSC approval of the PR
  • Create public-release
  • Update the API release tracker with public-release tag

Shall this subproject participate in the Meta-release?

[FabrizioMoggio]

Thank you. I will start working on this.

[FabrizioMoggio]

Actions (M1):

1. Fill the Umbrella release tracking page on CAMARA Wiki (https://wiki.camaraproject.org/display/CAM/CallForwardingSignal+API+Release+Tracking): example https://wiki.camaraproject.org/display/CAM/SimSwap+API+Release+Tracking
2. Create Release tracking page for Alpha version: example https://wiki.camaraproject.org/display/CAM/sim_swap++v0.5.0
3. Develop Alpha version: from 06/24 to 07/21 (we need to close: Intent-2: outputs proposal #31 (comment))
4. Develop Release-candidate from 07/21 to 08/31

[FabrizioMoggio]

according to the readiness Check list (New readiness checklist by FabrizioMoggio · Pull Request #43 · camaraproject/CallForwardingSignal (github.com))

• "Basic API test cases & documentation" are needed
• "Test result statement" are optional so we can create a "release-candidate" without an actual test result statement.

[FabrizioMoggio]

I just had a check with the release management team:

On M3 (07/21) the first release candidate must be released, between M3 and M4 a validation of the release candidate including bug fixing is performed. Additional release candidates if there were changes, the release candidate which is existing at M4 will get the actual public release.

So I propose this planning:

• final wip PR (Rel 0.2.0: conditional call fwd states update #48): approved and merged for 10/07
• Alpha on 10/07
• improve it if required and publish the Release-Candidate on 21/07
• than everyone can propose some fixing to it and we close with a final R-C on M4 (08/31)

[FabrizioMoggio]

API Tracker page creted and filled: https://wiki.camaraproject.org/display/CAM/Call+Forwarding+Signal+-+v0.2.0

[FabrizioMoggio]

From: CAMARA All Hands:

Reminder: the API version number within this first pre-release shall have the format x.y.z-rc.1 for the targeted release of API version x.y.z in the meta-release
Before M3 you may release 1 or more x.y.z-alpha.n versions as needed for the API development, but you can also go from the current release directly to the first release-candidate by M3. (Pre-)release numbering starts at r1.1. Please reflect this in the CHANGELOG.md.

[FabrizioMoggio]

Steps to create a Release:

• create a (pre-)release of the API, a release PR (linked to the associated release scope issue): Scope for Meta Release Fall 24 #49

• update of the API-Readiness-Checklist.md

• update of the Changelog.md

• update of the README.md (as necessary)

• once everything is approved create the Release Tag

[FabrizioMoggio]

After creating the release tag I need to update the Changelog file to reference to the just created release tag. @rartych Right?

[FabrizioMoggio]

After some further reasoning the process, in my understanding should be:

Steps to create a Release:

• create a (pre-)release of the API, a release PR (linked to the associated release scope issue): Scope for Meta Release Fall 24 #49

• update of the API-Readiness-Checklist.md

• update of the README.md (as necessary)

• once everything is approved create the Release Tag

• creation or update of the Changelog.md

• creation of the package for the release

[rartych]

@FabrizioMoggio I think you can have all the updates in the "release PR" see: https://wiki.camaraproject.org/display/CAM/API+Release+Process#APIReleaseProcess-PreparetheAPIrelease

The process is then:

• create a (pre-)release of the API, a release PR (linked to the associated release scope issue): Scope for Meta Release Fall 24 #49
  • the update of the version information in the API OAS definition file
  • update of the API-Readiness-Checklist.md
  • update of the README.md (as necessary)
  • creation or update of the Changelog.md
• once everything is approved create the Release Tag
• creation of the package for the release

For release numbering see:
https://wiki.camaraproject.org/display/CAM/API+Release+Process#APIReleaseProcess-APIreleasenumbering

[FabrizioMoggio]

I was exactly looking to those documents, although I had some doubt on when to create the Release Tag. I mean a reasonable process would be:

1. creating all the documents
2. take a snapshot with the release tag

this doesn't work because the changelog.md file includes links referred to the release tag

so the changelog.md file must be created after the release tag is done.

I couldn't find the right sequence in the documentation.

so I'm planning to follow these steps:

1. create a (pre-)release of the API, a release PR (linked to the associated release scope issue): Scope for Meta Release Fall 24 #49
2. the update of the version information in the API OAS definition file
3. update of the API-Readiness-Checklist.md
4. update of the README.md (as necessary)
5. once everything is approved create the Release Tag <--------------------------------------
6. creation or update of the Changelog.md <-------------------------------------------------
7. creation of the package for the release

[rartych]

You are right, but the links can be "anticipated" knowing the future Release Tag.

This approach is error prone (you can not test the links), but currently it is used.
With your approach the latest Changelog.md is not tagged with Release Tag, I guess.

[FabrizioMoggio]

that was my worry, but I was not sure. So I can try to anticipate the links.

let's go with:

After some further reasoning the process, in my understanding should be:

Steps to create a Release:

• create a (pre-)release of the API, a release PR (linked to the associated release scope issue): Scope for Meta Release Fall 24 #49

• update of the README.md (as necessary) with links to the future release anticipated

• creation or update of the Changelog.md with links to the future release anticipated

• update of the API-Readiness-Checklist.md

• once everything is approved create the Release Tag

• creation of the package for the release

[FabrizioMoggio]

According to:#59

We move go the RC:

Steps to create a Release:

• create a (pre-)release of the API, a release PR (linked to the associated release scope issue): Scope for Meta Release Fall 24 #49

• update of the README.md (as necessary) with links to the future release anticipated

• creation or update of the Changelog.md with links to the future release anticipated

• finalization of the Test Cases

• update of the Readiness Check List

• once everything is approved create the DRAFT Release Tag

• check that everything is correct

• make the Release Tag official