********************
Simultaneous Release
********************

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 the
`lftools sign <https://lf-releng-tools.readthedocs.io/en/latest/commands/sign.html>`_
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 distribution-karaf-x.y.z-${RELEASE}.tar.gz.asc distribution-karaf-x.y.z-${RELEASE}.tar.gz


Releasing OpenDaylight
======================

- Block submit permissions for registered users and elevate RE's committer
  rights on Gerrit.
  **(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.

- Nexus: click release for staging repo
  **(Helpdesk)**

- Nexus: click release for gpgsign repo (created above in Preparations)
  **(Helpdesk)**

- Pull latest autorelease repository
  **(Release Engineering Team)**

  .. note:: If you already cloned autorelease the clone line can be skipped below.

  .. code-block:: bash

     export RELEASE=Nitrogen-SR1
     export STREAM=${RELEASE//-*}
     export BRANCH=origin/stable/${STREAM,,}

     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 update --init

     # Ensure git review is setup
     git review -s
     git submodule foreach 'git review -s'

- Make sure the latest lftools is installed
  **(Release Engineering Team)**

  .. note:: If you already created an lftools virtualenv you can skip the mkvirtualenv step below.

  .. code-block:: bash

      mkvirtualenv lftools
      workon lftools
      pip install --upgrade lftools

- Publish release tags
  **(Release Engineering Team)**

  .. code-block:: bash

      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"

- Run autorelease-version-bump-${STREAM} job
  **(Release Engineering Team)**

- 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)**

- Merge all patches generated by the job
  **(Release Engineering Team)**

- Re-enable submit permissions for registered users and disable elevated RE
  committer rights on gerrit
  **(Helpdesk)**

- Send email to release/tsc/dev notifying tagging and version bump complete
  **(Release Engineering Team)**

- Run autorelease-generate-release-notes-${STREAM} job
  **(Release Engineering Team)**

  Trigger this job by leaving a Gerrit comment `generate-release-notes Carbon-SR2`

  .. important:: This job can only be used to generate service releases.

  For major releases the notes come from the projects themselves in the docs
  repo via the `docs/releaset-notes/projects` directory.

  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.