This page describes the process for creating a new CORD release. At a high-level, the process has two steps:
The first step to cutting a release is to create a support branch (e,g,, cord-3.0) on all the CORD repositories. This is done by an automated process, which can be triggered as follows:
specify the name of your support branch
;where it says revision="master", change master to the name of your support branch.
After the release-build job is triggered, it should create the support branch on all repositories in the manifest. The support branch is created from HEAD of each repository's master branch. The support branch can then be checked out using the -b argument to the repo init command, for example:
$ repo init -u https://gerrit.opencord.org/manifest -b cord-3.0
A release uses the manifest to specify a specific commit for each repository on the support branch. For example, if 3.0.0-rc1 and 3.0.1 are releases on the cord-3.0 support branch, each would have its own manifest specifying a different set of commits.
To cut a release:
At this point the release-build job will create a branch in the manifest repository for the release. The release manifest will contain commits for each repository corresponding to HEAD of the repository's support branch.
The steps in this section should be automated, but for now need to be performed manually:
The 4.0 release featured downloading published versions of the ONOS apps rather than building them from source. Since the ONOS apps are now handled like external packages, it was decided to remove them from the manifest. The ONOS app repositories were also added to the IGNORE_LIST in the Jenkinsfile so that the cord-4.0 branch would not be created on them.