This page explains how the OpenDaylight release process works once the TSC has
approved a release.
-Preparations
-============
-After release candidate is built gpg sign artifacts using odlsign-bulk script in
-**releng/builder/scripts**.
+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 Engienering Team during code freeze.
+
+ .. note::
+
+ Enable **Exclusive** checkbox for the submit button to override any
+ existing persmissions. Code-Review and Verify permissions are only needed
+ during version bumping.
+
+
+.. _simrel-preparations:
+
+Release Preparations
+====================
+
+After release candidate is built gpg sign artifacts using the
+:doc:`lftools sign <lftools:commands/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
- cd scripts/
- ./odlsign-bulk <staging-repo-id> # eg. autorelease-1367
+ 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
+ repos as well.
+
Releasing OpenDaylight
======================
-- Nexus: click release for staging repo **(Helpdesk)**
-- Nexus: click release for gpgsign repo (created above in Preparations) **(Helpdesk)**
-- Send email to Helpdesk with binary URL to update website **(Helpdesk)**
-- Send email to TSC and Release mailing lists announcing release binaries location **(Release Engineering Team)**
-- Checkout autorelease and switch to release branch eg stable/boron
+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 repos
+ **(Helpdesk)**
+
+ #. Select both the artifacts and signature repos
+ (:ref:`created previously <simrel-preparations>`) 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 persmissions. 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)**
-- Make sure your git repo is setup to push (use git-review)
- .. code-block:: bash
+ #. 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 PATCH_URL="https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/autorelease-release-${STREAM,,}/${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 <https://docs.opendaylight.org/en/latest/downloads.html>`_
+ 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
-- Download patches from Jenkins build page
+ .. warning::
- .. code-block:: bash
+ If this is a major release (eg. |release|) as opposed to a Service Release
+ (eg. |release|-SR1). Skip this step.
- cd /tmp
- wget https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-boron/230/artifact/patches/*zip*/patches.zip
- unzip patches.zip
+ For major releases the notes come from the projects themselves in the docs
+ repo via the `docs/releaset-notes/projects` directory.
-- Run the following commands for every project in the release
+ For service releases (SRs) we need to generate service release notes. This
+ can be performed by running the autorelease-generate-release-notes-$STREAM
+ job.
- .. code-block:: bash
+ #. Run the autorelease-generate-release-notes-${STREAM} job
+ **(Release Engineering Team)**
- ../scripts/patch-odl-release.sh /tmp/patches Boron
- git review -y -t Boron
- git push gerrit release/boron
+ Trigger this job by leaving a Gerrit comment
+ ``generate-release-notes Carbon-SR2``
-- Tag autorelease too
+ Release notes can also be manually generated with the script:
- .. code-block:: bash
+ .. code-block:: bash
- git submodule foreach git checkout release/beryllium
- git add [add each project individually to not pull in extra]
- git commit -sm "Release Beryllium"
- git tag -asm "OpenDaylight Beryllium release" release/beryllium
- git review -y -t Beryllium
- git push gerrit release/beryllium
+ git checkout stable/${BRANCH,,}
+ ./scripts/release-notes-generator.sh ${RELEASE}
-- Generate release notes (???)
-- Send email to release/tsc/dev notifying tagging and version bump complete **(Release Engineering Team)**
+ 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.