Simultaneous Release¶
This page explains how the OpenDaylight release process works once the TSC has approved a release.
Code Freeze¶
At the first Release Candidate (RC) the Submit
button is disabled on the
stable branch to prevent projects from merging non-blocking patches
into the release.
Disable
Submit
for Registered Users and allow permission to the Release Engineering Team (Helpdesk)Important
DO NOT enable Code-Review+2 and Verified+1 to the Release Engineering Team during code freeze.
Note
Enable Exclusive checkbox for the submit button to override any existing permissions. Code-Review and Verify permissions are only needed during version bumping.
This step can be achieved with the self-service job to lock or unlock a Gerrit
branch using autorelease-gerrit-branch-lock-${STREAM}
job on Jenkins CI.
Release Preparations¶
After release candidate is built GPG sign artifacts using the lftools sign command.
STAGING_REPO=autorelease-1903
STAGING_PROFILE_ID=abc123def456 # This Profile ID is listed in Nexus > Staging Profiles
lftools sign deploy-nexus https://nexus.opendaylight.org $STAGING_REPO $STAGING_PROFILE_ID
Verify the distribution-karaf file with the signature.
gpg2 --verify karaf-x.y.z-${RELEASE}.tar.gz.asc karaf-x.y.z-${RELEASE}.tar.gz
Note
Projects such as OpFlex participate in the Simultaneous Release but are not part of the autorelease build. Ping those projects and prep their staging repository as well.
Releasing OpenDaylight¶
The following describes the Simultaneous Release process for shipping out the binary and source code on release day.
Bulleted actions can be performed in parallel while numbered actions should be done in sequence.
Release the Nexus Staging repository (Helpdesk)
Select both the artifacts and signature repository (created previously) and
click Release
.Enter
Release OpenDaylight $RELEASE
for the description andclick confirm
.
Perform this step for any additional projects that are participating in the Simultaneous Release but are not part of the autorelease build.
Tip
This task takes hours to run so kicking it off early is a good idea.
Version bump for next dev cycle (Release Engineering Team)
Run the autorelease-version-bump-${STREAM} job
Tip
This task takes hours to run so kicking it off early is a good idea.
Enable
Code-Review+2
andVerify+1
voting permissions for theRelease Engineering Team
(Helpdesk)Note
Enable Exclusive checkbox for the submit button to override any existing permissions. Code-Review and Verify permissions are only needed during version bumping. DO NOT enable it during code freeze.
Merge all patches generated by the job
Restore Gerrit permissions for Registered Users and disable elevated Release Engineering Team permissions (Helpdesk)
Tag the release (Release Engineering Team)
Install lftools
lftools contains the version bumping scripts we need to version bump and tag the dev branches. We recommend using a virtualenv for this.
# Skip mkvirtualenv if you already have an lftools virtualenv mkvirtualenv lftools workon lftools pip install --upgrade lftools
Pull latest autorelease repository
export RELEASE=Nitrogen-SR1 export STREAM=${RELEASE//-*} export BRANCH=origin/stable/${STREAM,,} # No need to clean if you have already done it. git clone --recursive https://git.opendaylight.org/gerrit/releng/autorelease cd autorelease git fetch origin # Ensure we are on the right branch. Note that we are wiping out all # modifications in the repo so backup unsaved changes before doing this. git checkout -f git checkout ${BRANCH,,} git clean -xdff git submodule foreach git checkout -f git submodule foreach git clean -xdff git submodule update --init # Ensure git review is setup git review -s git submodule foreach 'git review -s'
Publish release tags
export BUILD_NUM=55 export OPENJDKVER="openjdk17" export PATCH_URL="https://s3-logs.opendaylight.org/logs/releng/vex-yul-odl-jenkins-1/autorelease-release-${STREAM,,}-mvn38-${OPENJDKVER}/${BUILD_NUM}/patches.tar.gz" ./scripts/release-tags.sh "${RELEASE}" /tmp/patches "$PATCH_URL"
Notify Community and Website teams
Update downloads page
Submit a patch to the ODL docs project to update the downloads page with the latest binaries and packages (Release Engineering Team)
Email dev/release/tsc mailing lists announcing release binaries location (Release Engineering Team)
Email dev/release/tsc mailing lists to notify of tagging and version bump completion (Release Engineering Team)
Note
This step is performed after Version Bump and Tagging steps are complete.
Generate Service Release notes
Warning
If this is a major release (eg. Potassium) as opposed to a Service Release (eg. Potassium-SR1). Skip this step.
For major releases the notes come from the projects themselves in the docs repository via the docs/releaset-notes/projects directory.
For service releases (SRs) we need to generate service release notes. This can be performed by running the autorelease-generate-release-notes-$STREAM job.
Run the autorelease-generate-release-notes-${STREAM} job (Release Engineering Team)
Trigger this job by leaving a Gerrit comment
generate-release-notes Carbon-SR2
Release notes can also be manually generated with the script:
git checkout stable/${BRANCH,,} ./scripts/release-notes-generator.sh ${RELEASE}
A
release-notes.rst
will be generated in the working directory. Submit this file asrelease-notes-sr1.rst
(update thesr
as necessary) to the docs project.