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
- cd scripts/
- ./odlsign-bulk STAGING_REPO_ID # eg. autorelease-1367
+ 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 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. **(Helpdesk)**
+The following describes the Simultaneous Release process for shipping out the
+binary and source code on release day.
- .. figure:: images/gerrit-update-committer-rights.png
+Bulleted actions can be performed in parallel while numbered actions should be
+done in sequence.
- .. note::
+- Release the Nexus Staging repos
+ **(Helpdesk)**
- Enable Exclusive checkbox
+ #. Select both the artifacts and signature repos
+ (:ref:`created previously <simrel-preparations>`) and ``click Release``.
-- Export ${RELEASE} and ${BUILDNUM} with current release name and build number.
+ #. Enter ``Release OpenDaylight $RELEASE`` for the description and
+ ``click confirm``.
- .. code-block:: bash
+ *Perform this step for any additional projects that are participating in
+ the Simultaneous Release but are not part of the autorelease build.*
- export RELEASE=Beryllium-SR4
- export BRANCH=${RELEASE//-*}
- export BUILDNUM=55
+ .. tip::
-- 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)**
-- Clone autorelease repository. **(Release Engineering Team)**
+ This task takes hours to run so kicking it off early is a good idea.
- .. code-block:: bash
+- Version bump for next dev cycle
+ **(Release Engineering Team)**
- git clone --recursive https://git.opendaylight.org/gerrit/releng/autorelease
+ #. Run the autorelease-version-bump-${STREAM} job
-- Checkout autorelease and switch to release branch eg stable/carbon **(Release Engineering Team)**
+ .. tip::
- .. code-block:: bash
+ This task takes hours to run so kicking it off early is a good idea.
- git checkout -b stable/${BRANCH,,} origin/stable/${BRANCH,,}
- git submodule update --init
- git submodule foreach git checkout -b stable/${BRANCH,,} origin/stable/${BRANCH,,}
+ #. Enable ``Code-Review+2`` and ``Verify+1`` voting permissions
+ for the ``Release Engineering Team``
+ **(Helpdesk)**
-- Make sure your git repo is setup to push (use git-review)
+ .. figure:: images/gerrit-update-committer-rights.png
- .. code-block:: bash
+ .. note::
- git review -s
- git submodule foreach 'git review -s'
+ 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.
-- Download patches (\*.bundle files and taglist.log.gz) from log server.
+ #. Merge all patches generated by the job
- .. code-block:: bash
+ #. Restore Gerrit permissions for *Registered Users* and disable elevated
+ *Release Engineering Team* permissions
+ **(Helpdesk)**
- mkdir /tmp/patches && cd /tmp/patches
- wget https://logs.opendaylight.org/releng/jenkins092/autorelease-release-${BRANCH,,}/${BUILDNUM}/archives/all-bundles.tar.gz
- gunzip all-bundles.tar.gz
- wget https://logs.opendaylight.org/releng/jenkins092/autorelease-release-${BRANCH,,}/${BUILDNUM}/archives/patches/taglist.log.gz
- gunzip taglist.log.gz
+- Tag the release
+ **(Release Engineering Team)**
-- Run the following commands for every project in the release, to apply patches to each project directory.
+ #. Install lftools
- .. code-block:: bash
+ lftools contains the version bumping scripts we need to version bump
+ and tag the dev branches. We recommend using a virtualenv for this.
- pip install lftools
- lftools version patch ${RELEASE}
- git review -y -t ${RELEASE}
- git push gerrit release/${RELEASE,,}
+ .. code-block:: bash
-- Merge all patches on gerrit in the order generated by merge-order.log
+ # Skip mkvirtualenv if you already have an lftools virtualenv
+ mkvirtualenv lftools
+ workon lftools
+ pip install --upgrade lftools
-- Tag autorelease too
+ #. Pull latest autorelease repository
- .. code-block:: bash
+ .. code-block:: bash
- git checkout `cat /tmp/patches/taglist.log | grep autorelease | awk '{print $2}'`
- git submodule foreach git checkout release/${RELEASE,,}
- git commit -asSm "Release ${RELEASE}"
- git tag -asm "OpenDaylight ${RELEASE} release" release/${RELEASE,,}
- git push gerrit release/${RELEASE,,}
+ export RELEASE=Nitrogen-SR1
+ export STREAM=${RELEASE//-*}
+ export BRANCH=origin/stable/${STREAM,,}
-- Re-enable submit permissions for registered users and disable elevated RE committer rights on gerrit.
+ # 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
-- Release notes is auto generated by job autorelease-generate-release-notes-${BRANCH,,}
- triggered at the end of every autorelease build. The release notes file (release_notes.rst) is
- available under archives.
+ # 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
- Alternatively, release notes can also be manually generated with the script.
- **(Release Engineering Team)**
+ # 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)**
+
+ 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,,}
- cd scripts/release_notes_management/ && ./build.sh
-
- The output file (release_notes.rst) generated by the build script is available under autorelease/scripts/release_notes_management/projects/.
+ ./scripts/release-notes-generator.sh ${RELEASE}
-- 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.
Code Review / docs.git / blobdiff