******************** 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)** .. figure:: images/gerrit-update-committer-rights.png .. 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. .. _simrel-preparations: Release Preparations ==================== After release candidate is built GPG sign artifacts using the :doc:`lftools sign ` command. .. code-block:: bash 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. .. code-block:: bash 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 (:ref:`created previously `) and ``click Release``. #. 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)** #. 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`` and ``Verify+1`` voting permissions for the ``Release Engineering Team`` **(Helpdesk)** .. figure:: images/gerrit-update-committer-rights.png .. 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. .. code-block:: bash # Skip mkvirtualenv if you already have an lftools virtualenv mkvirtualenv lftools workon lftools pip install --upgrade lftools #. Pull latest autorelease repository .. code-block:: bash 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 .. code-block:: bash 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 #. 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. |release|) as opposed to a Service Release (eg. |release|-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: .. code-block:: bash 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.