Maintenance Releases:

(Using F-Maintenance release as an example here)

Overall Steps

Cherrypick & release as below (More details below)
Update image version numbers on release wikipages, e.g. in:
Check version numbers used in documentation
- RTD, WIKI, ReadMe’s,
- E.g. https://lf-o-ran-sc.atlassian.net/wiki/display/RICNR/Release+F+-+Run+in+Docker
Update versions in tests
Update in helm charts & dockerfile(s)

Cherry-picking & Releasing

(Tasks must be performed in the correct order!)

Checkout Release branch (e.g. f-release)
Update version number in pom.xml or container-tag.yaml in Release Branch
- ... otherwise previous released version will be partly overwritten – and release will fail (see below)
- ... only if version numbers were not updated in after the last release)
- For example, Information Coordinator Service
  - (Java) Pom: pom.xml
    - https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/informationcoordinatorservice/+/8931/2/pom.xml
  - (Golang or Python - No POM file) container-tag.yaml
    - https://gerrit.o-ran-sc.org/r/c/sim/a1-interface/+/8933/2/near-rt-ric-simulator/container-tag.yamlFor example, A1 Simulator
Cherrypick changes as needed - either one at a time or as a squashed commit (see below)
- Do in reverse order – oldest -> newest
- .. then commit & review & merge the change to the branch
Create Staging release
- Last cherrypick above once complete should create, a new Staging image (& maven artifacts if maven releases are used) using version numbers in pom.xml or container-tag.yaml
- (If no cherry pick, or no update in 30 days last commit on branch should be re-merged – will create snapshot)
- (Note, it seems GO projects do not need a staging image. But may need a recent snapshot build. Skip this step)
- Some repos do NOT have a staging image automatically created.
  - See https://lf-o-ran-sc.atlassian.net/wiki/display/ORAN/O-RAN+Developer%27s+Guide+to+CI+Resources+and+Processes+at+the+LF#ORANDeveloper'sGuidetoCIResourcesandProcessesattheLF-TriggeringJenkinsjobsfromGerrit
  - To manually trigger staging use comment “stage-release” on the relevant gerrit review to create a staging image. (Note this job also strips “–SNAPSHOT” from the image name if –SNAPSHOT is used)
- Useful link to view if tagged staging image is created/correct: https://nexus3.o-ran-sc.org/#browse/browse:docker.staging:v2%2Fo-ran-sc
Release Staged Image (from Release branch)
- Find commit ID for last commit (e.g. git log –all)
- Edit & commit container file in /.releases folder
  - See https://lf-o-ran-sc.atlassian.net/wiki/display/ORAN/O-RAN+Developer%27s+Guide+to+CI+Resources+and+Processes+at+the+LF#ORANDeveloper'sGuidetoCIResourcesandProcessesattheLF-ReleasingaDockerartifact
  - For Example: A1 Policy Management Service: https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/a1policymanagementservice/+/8953
  - ... make sure to update BOTH of the version numbers to the latest version
  - ... similar process in ONAP https://wiki.onap.org/pages/viewpage.action?pageId=68545910
  - Documentation of this step: https://github.com/lfit/releng-global-jjb/blob/master/docs/jjb/lf-release-jobs.rst && https://lf-o-ran-sc.atlassian.net/wiki/display/ORAN/O-RAN+Developer%27s+Guide+to+CI+Resources+and+Processes+at+the+LF#ORANDeveloper'sGuidetoCIResourcesandProcessesattheLF-ReleasingaDockerartifact
- Review will not pass ‘verify’ step if the referenced snapshot/staging image cannot be found
- Merge the commit, which will trigger the release operation
  - On merge, image will appear in ‘releases’ docker repo,
  - This job literally copies the referenced version from the source image store/repo (docker-staging) into the target image store/repo (docker-releases)
  - This job also performs git tag (<version number>) added to the referenced commit above.
- Note, this can only be done ONCE for each release version – re-runs of this operation will not upload a new image with the same version number. Messed-up release images cannot be removed. If you make a mistake at this stage you must start again with a new version number.
- Useful link to view if tagged released image is correct: https://nexus3.o-ran-sc.org/#browse/browse:docker.release:v2%2Fo-ran-sc
Release Staged Maven artifacts – if enabled
- Find Jenkins staging job id for the commit to release (e.g. the last cherrypick above)
  - For example, for Information coordinator Service the appropriate job is nonrtric -plt -informationcoordinatorservice -maven-stage-f-release defined in ci-management repo …
  - The job ID will be visible in the comments/log of the appropriate commit that generated the staged version (e.g. the last cherrypick above, or the commit with 'stage-release' triggering comment)
- Edit & commit maven file in the in /.releases folder
  - For example e.g. for Information coordinator Service
    - https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/informationcoordinatorservice/+/8944
  - Documentation of this step: https://github.com/lfit/releng-global-jjb/blob/master/docs/jjb/lf-release-jobs.rst && https://lf-o-ran-sc.atlassian.net/wiki/display/ORAN/O-RAN+Developer%27s+Guide+to+CI+Resources+and+Processes+at+the+LF#ORANDeveloper'sGuidetoCIResourcesandProcessesattheLF-ReleasingaJava/mavenartifact
- On merge, maven artifact will appear in ‘releases’ maven repo
- Useful site to browse the maven repo to check maven artifact version is present: https://nexus.o-ran-sc.org/content/repositories/releases/org/o-ran-sc/
Update Release Notes in Release Branch AND master branch – add commit ID of the release commit
- For example, for Information coordinator Service:
  - f release branch /docs/release-notes.rst
    - https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/informationcoordinatorservice/+/8948
  - master branch /docs/release-notes.rst
    - https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/informationcoordinatorservice/+/8947
Uptick version number AGAIN in pom.xml or container-tag.yaml in Release Branch (See step 2 above)
- For example, Information Coordinator Service
  - (Java) Pom: pom.xml
    - https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/informationcoordinatorservice/+/8958
- For example, A1 Simulator
  - (Golang or Python - No POM file) container-tag.yaml
    - https://gerrit.o-ran-sc.org/r/c/sim/a1-interface/+/8957/1/near-rt-ric-simulator/container-tag.yaml
Now find & fix all documentation, tests, script file, helm charts etc referring to the old version number! :-O

How to Cherry Pick lots of commits as a single Squashed Commit

Checkout Release branch (e.g. f-release)
$ git review –l
- List reviews if exists
$ git review -d <change_id>
- Download the review if exists)
$ git cherry-pick <commit_hash_3> <commit_hash_2> <commit_hash_1> ….
- Cherry pick desired commits in order from oldest to youngest
$ git status
- Check branch status to see how many commits your branch is ahead
$ git rebase -i HEAD~<diff_commit_count_number> (diff_commit_count_number: the number of commits cherrypicked in prev. step)
- When the git edit window is opened, leave the pick on the first and replace 'pick' with 's' on the remaining commits.
  - :wq (to save/exit squashing (if using vi as git edit))
- When the git edit window is opened for second time to edit commit messages, edit them all as you needed
  - :wq (to save/exit commit message editing (if using vi as git edit))
$ git status
- Now you see that only one commit ahead
$ git commit –amend
- You may change your commit message as you needed e.g. Patch set 2: Squash commits and cherry pick
$ git review --verbose --dry-run branchname
- dry-run review operation before apply, Do not forget the branchname! e.g. f-release, be careful when pointing <parent_branch_info>
$ git review --verbose branchname
- send your review that includes the squashed commit as a new patch set on the same change_id checked-out at ‘git review –d’ step above

Note about squashing cherrypicks

One issue with this approach is that the trail back to the original commit is lost.
The new squashed commit appears as a new standalone commit
With a 'standard' cherrypick each cherry-picked commit can still be tracked back to its original commit.
At the very least the commit message for the squashed commit should refer back to the change-IDs or commit-IDs of the original cherrypicked commit