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

This page explains how the OpenDaylight release process works once the TSC has
approved a release.


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 Engineering Team during code freeze.

   .. note::

      Enable **Exclusive** checkbox for the submit button to override any
      existing permissions. Code-Review and Verify permissions are only needed
      during version bumping.

This step can be achieved with the self-service job to lock or unlock a Gerrit
branch using ``autorelease-gerrit-branch-lock-${STREAM}`` job on Jenkins CI.


.. _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

    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
   repository as well.


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

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 repository
  **(Helpdesk)**

  #. Select both the artifacts and signature repository
     (: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 permissions. 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)**

  #. 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 OPENJDKVER="openjdk21"
        export PATCH_URL="https://s3-logs.opendaylight.org/logs/releng/vex-yul-odl-jenkins-1/autorelease-release-${STREAM,,}-mvn39-${OPENJDKVER}/${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
  repository 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,,}
      ./scripts/release-notes-generator.sh ${RELEASE}

  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.