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)
1. Select both the artifacts and signature repository (created previously) and click Release.
2. Enter Release OpenDaylight $RELEASE for the description and click 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)
1. Run the autorelease-version-bump-${STREAM} job
  
  Tip
  
  This task takes hours to run so kicking it off early is a good idea.
2. Enable Code-Review+2 and Verify+1 voting permissions for the Release 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.
3. Merge all patches generated by the job
4. 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="openjdk11"
export PATCH_URL="https://s3-logs.opendaylight.org/logs/releng/vex-yul-odl-jenkins-1/autorelease-release-${STREAM,,}-mvn35-${OPENJDKVER}/${BUILD_NUM}/patches.tar.gz"
./scripts/release-tags.sh "${RELEASE}" /tmp/patches "$PATCH_URL"

Notify Community and Website teams
1. 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)
2. Email dev/release/tsc mailing lists announcing release binaries location (Release Engineering Team)
3. 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. Scandium) as opposed to a Service Release (eg. Scandium-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.
1. 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 as release-notes-sr1.rst (update the sr as necessary) to the docs project.