This page explains how the OpenDaylight release process works once the TSC has
approved a release.
-Preparations
-============
+
+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
-`lftools sign <https://lf-releng-tools.readthedocs.io/en/latest/commands/sign.html>`_
-command.
+:doc:`lftools sign <lftools:commands/sign>` command.
.. code-block:: bash
.. code-block:: bash
- gpg2 --verify distribution-karaf-x.y.z-${RELEASE}.tar.gz.asc distribution-karaf-x.y.z-${RELEASE}.tar.gz
+ 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
======================
-- Block submit permissions for registered users and elevate RE's committer
- rights on Gerrit.
+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)**
- .. figure:: images/gerrit-update-committer-rights.png
+ #. Select both the artifacts and signature repos
+ (:ref:`created previously <simrel-preparations>`) and ``click Release``.
- .. note::
+ #. Enter ``Release OpenDaylight $RELEASE`` for the description and
+ ``click confirm``.
- 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.
+ *Perform this step for any additional projects that are participating in
+ the Simultaneous Release but are not part of the autorelease build.*
-- Nexus: click release for staging repo
- **(Helpdesk)**
+ .. tip::
-- Nexus: click release for gpgsign repo (created above in Preparations)
- **(Helpdesk)**
+ This task takes hours to run so kicking it off early is a good idea.
-- Pull latest autorelease repository
+- Version bump for next dev cycle
**(Release Engineering Team)**
- .. note:: If you already cloned autorelease the clone line can be skipped below.
+ #. Run the autorelease-version-bump-${STREAM} job
- .. code-block:: bash
+ .. tip::
- git clone --recursive https://git.opendaylight.org/gerrit/releng/autorelease
- cd autorelease
- git submodule update --init
- git review -s
- git submodule foreach 'git review -s'
+ This task takes hours to run so kicking it off early is a good idea.
-- Make sure the latest lftools is installed
- **(Release Engineering Team)**
+ #. Enable ``Code-Review+2`` and ``Verify+1`` voting permissions
+ for the ``Release Engineering Team``
+ **(Helpdesk)**
- .. note:: If you already created an lftools virtualenv you can skip the mkvirtualenv step below.
+ .. figure:: images/gerrit-update-committer-rights.png
- .. code-block:: bash
+ .. 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.
- mkvirtualenv lftools
- workon lftools
- pip install --upgrade lftools
+ #. Merge all patches generated by the job
-- Publish release tags
+ #. Restore Gerrit permissions for *Registered Users* and disable elevated
+ *Release Engineering Team* permissions
+ **(Helpdesk)**
+
+- Tag the release
**(Release Engineering Team)**
- .. code-block:: bash
+ #. Install lftools
- export RELEASE=Beryllium-SR4
- export STREAM=${RELEASE//-*}
- export BUILD_NUM=55
- export PATCH_URL="https://logs.opendaylight.org/releng/jenkins092/autorelease-release-${STREAM,,}/${BUILD_NUM}/patches.tar.gz"
- ./scripts/release-tags.sh "${RELEASE}" /tmp/patches "$PATCH_URL"
+ lftools contains the version bumping scripts we need to version bump
+ and tag the dev branches. We recommend using a virtualenv for this.
-- Run autorelease-version-bump-${STREAM} job
- **(Release Engineering Team)**
+ .. code-block:: bash
-- Send email to Helpdesk with binary URL to update website
- **(Helpdesk)**
+ # Skip mkvirtualenv if you already have an lftools virtualenv
+ mkvirtualenv lftools
+ workon lftools
+ pip install --upgrade lftools
-- Send email to TSC and Release mailing lists announcing release binaries location
- **(Release Engineering Team)**
+ #. Pull latest autorelease repository
-- Merge all patches generated by the job
- **(Release Engineering Team)**
+ .. code-block:: bash
-- Re-enable submit permissions for registered users and disable elevated RE
- committer rights on gerrit
- **(Helpdesk)**
+ export RELEASE=Nitrogen-SR1
+ export STREAM=${RELEASE//-*}
+ export BRANCH=origin/stable/${STREAM,,}
-- Send email to release/tsc/dev notifying tagging and version bump complete
- **(Release Engineering Team)**
+ # 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
-- Run autorelease-generate-release-notes-${STREAM} job
- **(Release Engineering Team)**
+ # 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
+
+ .. 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
+ repo 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)**
- This job is run a the end of every autorelease build can be used only for
- service releases (SR). The release notes file (release_notes.rst) is available
- under archives. For major releases (Nitrogen, Carbon) the docs repository has
- to branched and published which is only done after release reviews are
- completed.
+ Trigger this job by leaving a Gerrit comment
+ ``generate-release-notes Carbon-SR2``
- Release notes can also be manually generated with the script.
+ Release notes can also be manually generated with the script:
.. code-block:: bash
git checkout stable/${BRANCH,,}
- cd scripts/release_notes_management/ && ./build.sh
+ ./scripts/release-notes-generator.sh ${RELEASE}
- The output file (release_notes.rst) generated by the build script is available
- under autorelease/scripts/release_notes_management/projects/.
+ 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.
Code Review / docs.git / blobdiff