docs/release-process/simultaneous-release.rst

   1 ********************
   2 Simultaneous Release
   3 ********************
   4
   5 This page explains how the OpenDaylight release process works once the TSC has
   6 approved a release.
   7
   8
   9 Code Freeze
  10 ===========
  11
  12 At the first Release Candidate (RC) the ``Submit`` button is disabled on the
  13 stable branch to prevent projects from merging non-blocking patches
  14 into the release.
  15
  16 #. Disable ``Submit`` for *Registered Users* and allow permission to the
  17    *Release Engineering Team*
  18    **(Helpdesk)**
  19
  20    .. figure:: images/gerrit-update-committer-rights.png
  21
  22    .. important::
  23
  24       **DO NOT** enable Code-Review+2 and Verified+1 to the
  25       Release Engineering Team during code freeze.
  26
  27    .. note::
  28
  29       Enable **Exclusive** checkbox for the submit button to override any
  30       existing permissions. Code-Review and Verify permissions are only needed
  31       during version bumping.
  32
  33
  34 .. _simrel-preparations:
  35
  36 Release Preparations
  37 ====================
  38
  39 After release candidate is built GPG sign artifacts using the
  40 :doc:`lftools sign <lftools:commands/sign>` command.
  41
  42 .. code-block:: bash
  43
  44     STAGING_REPO=autorelease-1903
  45     STAGING_PROFILE_ID=abc123def456  # This Profile ID is listed in Nexus > Staging Profiles
  46     lftools sign deploy-nexus https://nexus.opendaylight.org $STAGING_REPO $STAGING_PROFILE_ID
  47
  48 Verify the distribution-karaf file with the signature.
  49
  50 .. code-block:: bash
  51
  52     gpg2 --verify karaf-x.y.z-${RELEASE}.tar.gz.asc karaf-x.y.z-${RELEASE}.tar.gz
  53
  54 .. note::
  55
  56    Projects such as OpFlex participate in the Simultaneous Release but are not
  57    part of the autorelease build. Ping those projects and prep their staging
  58    repository as well.
  59
  60
  61 Releasing OpenDaylight
  62 ======================
  63
  64 The following describes the Simultaneous Release process for shipping out the
  65 binary and source code on release day.
  66
  67 Bulleted actions can be performed in parallel while numbered actions should be
  68 done in sequence.
  69
  70 - Release the Nexus Staging repository
  71   **(Helpdesk)**
  72
  73   #. Select both the artifacts and signature repository
  74      (:ref:`created previously <simrel-preparations>`) and ``click Release``.
  75
  76   #. Enter ``Release OpenDaylight $RELEASE`` for the description and
  77      ``click confirm``.
  78
  79   *Perform this step for any additional projects that are participating in
  80   the Simultaneous Release but are not part of the autorelease build.*
  81
  82   .. tip::
  83
  84      This task takes hours to run so kicking it off early is a good idea.
  85
  86 - Version bump for next dev cycle
  87   **(Release Engineering Team)**
  88
  89   #. Run the autorelease-version-bump-${STREAM} job
  90
  91      .. tip::
  92
  93         This task takes hours to run so kicking it off early is a good idea.
  94
  95   #. Enable ``Code-Review+2`` and ``Verify+1`` voting permissions
  96      for the ``Release Engineering Team``
  97      **(Helpdesk)**
  98
  99      .. figure:: images/gerrit-update-committer-rights.png
 100
 101      .. note::
 102
 103         Enable **Exclusive** checkbox for the submit button to override any
 104         existing permissions. Code-Review and Verify permissions are only needed
 105         during version bumping. **DO NOT** enable it during code freeze.
 106
 107   #. Merge all patches generated by the job
 108
 109   #. Restore Gerrit permissions for *Registered Users* and disable elevated
 110      *Release Engineering Team* permissions
 111      **(Helpdesk)**
 112
 113 - Tag the release
 114   **(Release Engineering Team)**
 115
 116   #. Install lftools
 117
 118      lftools contains the version bumping scripts we need to version bump
 119      and tag the dev branches. We recommend using a virtualenv for this.
 120
 121      .. code-block:: bash
 122
 123         # Skip mkvirtualenv if you already have an lftools virtualenv
 124         mkvirtualenv lftools
 125         workon lftools
 126         pip install --upgrade lftools
 127
 128   #. Pull latest autorelease repository
 129
 130      .. code-block:: bash
 131
 132         export RELEASE=Nitrogen-SR1
 133         export STREAM=${RELEASE//-*}
 134         export BRANCH=origin/stable/${STREAM,,}
 135
 136         # No need to clean if you have already done it.
 137         git clone --recursive https://git.opendaylight.org/gerrit/releng/autorelease
 138         cd autorelease
 139         git fetch origin
 140
 141         # Ensure we are on the right branch. Note that we are wiping out all
 142         # modifications in the repo so backup unsaved changes before doing this.
 143         git checkout -f
 144         git checkout ${BRANCH,,}
 145         git clean -xdff
 146         git submodule foreach git checkout -f
 147         git submodule foreach git clean -xdff
 148         git submodule update --init
 149
 150         # Ensure git review is setup
 151         git review -s
 152         git submodule foreach 'git review -s'
 153
 154   #. Publish release tags
 155
 156      .. code-block:: bash
 157
 158         export BUILD_NUM=55
 159         export OPENJDKVER="openjdk11"
 160         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"
 161         ./scripts/release-tags.sh "${RELEASE}" /tmp/patches "$PATCH_URL"
 162
 163 - Notify Community and Website teams
 164
 165   #. Update downloads page
 166
 167      Submit a patch to the ODL docs project to update the
 168      `downloads <https://docs.opendaylight.org/en/latest/downloads.html>`_
 169      page with the latest binaries and packages **(Release Engineering Team)**
 170
 171   #. Email dev/release/tsc mailing lists announcing release binaries location
 172      **(Release Engineering Team)**
 173
 174   #. Email dev/release/tsc mailing lists to notify of tagging and version bump
 175      completion
 176      **(Release Engineering Team)**
 177
 178      .. note::
 179
 180         This step is performed after Version Bump and Tagging steps are
 181         complete.
 182
 183 - Generate Service Release notes
 184
 185   .. warning::
 186
 187      If this is a major release (eg. |release|) as opposed to a Service Release
 188      (eg. |release|-SR1). Skip this step.
 189
 190   For major releases the notes come from the projects themselves in the docs
 191   repository via the `docs/releaset-notes/projects` directory.
 192
 193   For service releases (SRs) we need to generate service release notes. This
 194   can be performed by running the autorelease-generate-release-notes-$STREAM
 195   job.
 196
 197   #. Run the autorelease-generate-release-notes-${STREAM} job
 198      **(Release Engineering Team)**
 199
 200      Trigger this job by leaving a Gerrit comment
 201      ``generate-release-notes Carbon-SR2``
 202
 203   Release notes can also be manually generated with the script:
 204
 205   .. code-block:: bash
 206
 207       git checkout stable/${BRANCH,,}
 208       ./scripts/release-notes-generator.sh ${RELEASE}
 209
 210   A ``release-notes.rst`` will be generated in the working directory. Submit
 211   this file as ``release-notes-sr1.rst`` (update the ``sr`` as necessary) to the
 212   docs project.