===============
Release process
===============

This document describes the process for making a Bodhi release.


Branches
========

Bodhi follows `semantic versioning`_, and so backwards incompatible changes get a major release,
releases with new features get a minor release, and releases that only contain bug fixes get a patch
release.

To aid in maintaining this scheme, Bodhi uses branches named with the scheme ``major.minor`` to keep
track of feature releases. Once a ``major.minor`` branch is created and a release is tagged, only
bugfixes should be added to that branch.

When you wish to make a patch release, simply cherry pick (described below) the patches you wish to
include in the release to the appropriate ``major.minor`` branch.

If you wish to make a minor release, you will need to create a new ``major.minor`` branch.
Typically we would do this by branching from a desired commit on the ``develop`` branch, unless
there are backwards incompatible changes in ``develop``. If ``develop`` has backwards incompatible
commits that we don't want to release with, you should branch from the most recent ``major.minor``
branch, and then cherry pick the desired commits from ``develop``.

Of course, if you want to make a new major release, simply create a ``major.minor`` branch from the
desired commit on ``develop``.


Cherry picking
--------------

To simplify the release process, almost all patches are sent to the ``develop`` branch. Once they
are reviewed and merged, they can be cherry picked to a ``major.minor`` branch if desired. To aid in
this process, we use `Mergify`_'s `patch backporting feature`_. For each actively maintained
release there should be a backporting action in the Mergify config and an associated GitHub label.
For example, as of the time of this writing we have active 3.12 and 3.13 branches, so we have GitHub
labels called ``3.12-backports`` and ``3.13-backports``. Any pull requests tagged with either of
these tags will cause Mergify to backport the associated patch to the relevant branch via a new pull
request.

.. note:: The backporting feature is configured in ``.mergify.yml``.


How to make a release
=====================

Preparation
-----------

#. If you are making a new major or minor release:

   a. Create the new ``major.minor`` branch in the upstream Bodhi repository.
   b. Prepare the ``.mergify.yml`` file for the new ``major.minor`` branch as described above.
   c. Configure ``devel/ci/cico.pipeline`` to check out the ``major.minor`` branch so it is
      available to ``diff-cover`` later. This is needed to get ``diff-cover`` to be able to compare
      against the new ``major.minor`` branch. You can find the spot to do this by searching for
      the mention of ``diff-cover`` in a comment. An example is available in
      `this pull request <https://github.com/fedora-infra/bodhi/pull/2916>`_.
   d. Similarly, we need to adjust ``diff-cover`` to use the new ``major.minor`` branch for
      comparison in ``devel/ci/bodhi-ci``. You can find the spot to edit by searching for the
      ``--compare-branch`` flag being passed to ``diff-cover``.

#. Raise the version to the appropriate value in ``setup.py`` and ``docs/conf.py``.
#. Use ``git log`` to find all commits that are new in this release and use the commit messages to
   write release notes in ``docs/user/release_notes.rst``. You can filter ``git log`` to show commit
   that differ between two git refs to help. For example, to see differences between ``3.12`` and
   ``3.13``, you could use ``git log 3.12..3.13``. Be aware that any commits that were cherry picked
   to ``3.12`` will show up in this example and we wouldn't want to mark those commits as being new
   in ``3.13``.
#. Add a note to all the associated issues and pull requests to let them know they will be included
   in this release.


Build a beta
------------

Bodhi uses the `Fedora Rawhide spec file`_ to build production RPMs for the
`Fedora Infrastructure repositories`_. As upstream Bodhi does not have any infrastructure of its own
for beta testing, we use `Fedora's staging instance`_ of Bodhi to do our beta testing. Thus, in
order to build and test the beta using these instructions, you will need administrative access to
the staging Bodhi deployment and you will need access to build in the staging infrastructure
repository.

To build the beta, follow these steps:

#. Clone the Bodhi spec file repository::

   $ fedpkg clone bodhi

#. Alter the spec file to build the commit you want to test rather than a tagged release. Use a
   value less than one for the release field on betas (for example the first might be 0.0, the
   second might be 0.1, and so on). For example, to test
   ``e0ca5bc5d36e8cca5bd126879a036006356645e6`` (which is a 3.13 beta), a patch like this will
   work::

    $ git diff
    diff --git a/bodhi.spec b/bodhi.spec
    index eaf3415..d3684be 100644
    --- a/bodhi.spec
    +++ b/bodhi.spec
    @@ -1,16 +1,21 @@
     %global bashcompdir     %(pkg-config --variable=completionsdir bash-completion 2>/dev/null)
     %global bashcomproot    %(dirname %{bashcompdir} 2>/dev/null)
     
    +%global commit e0ca5bc5d36e8cca5bd126879a036006356645e6
    +%global commit_short %(c=%{commit}; echo ${c:0:7})
    +
     Name:           bodhi
    -Version:        3.12.0
    -Release:        100%{?dist}
    +Version:        3.13.0
    +Release:        0.0.beta.%{commit_short}%{?dist}
     BuildArch:      noarch
     
     License:        GPLv2+
     Summary:        A modular framework that facilitates publishing software updates
     Group:          Applications/Internet
     URL:            https://github.com/fedora-infra/bodhi
    -Source0:        %{url}/archive/%{version}/%{name}-%{version}.tar.gz
    +Source0:        %{url}/archive/%{commit}/%{name}-%{commit}.tar.gz
    +Patch0:         0000-Set-the-version-to-beta-0.patch
     
     BuildRequires: %{py2_dist click}
     BuildRequires: %{py2_dist iniparse}
    @@ -241,7 +248,7 @@ updates for a software distribution.
     
     
     %prep
    -%autosetup -p1 -n bodhi-%{version}
    +%autosetup -p1 -n bodhi-%{commit}
     
     # Kill some dev deps
     sed -i '/pyramid_debugtoolbar/d' setup.py
    @@ -270,7 +277,7 @@ make %{?_smp_mflags} -C docs man
     %install
     %py2_install
     # Let's remove all the server stuff since we don't ship Python 2 version of the server anymore.
    -rm -rf %{buildroot}/%{python2_sitelib}/%{name}_server-%{version}-py%{python2_version}.egg-info
    +rm -rf %{buildroot}/%{python2_sitelib}/%{name}_server-%{version}b0-py%{python2_version}.egg-info
     rm -rf %{buildroot}/%{python2_sitelib}/%{name}/server
     %py3_install
     
    @@ -346,7 +353,7 @@ rm .coveragerc
     %doc README.rst
     %dir %{python2_sitelib}/%{name}/
     %{python2_sitelib}/%{name}/__init__.py*
    -%{python2_sitelib}/%{name}-%{version}-py%{python2_version}.egg-info
    +%{python2_sitelib}/%{name}-%{version}b0-py%{python2_version}.egg-info
     
     
     %files -n python3-bodhi
    @@ -355,21 +362,21 @@ rm .coveragerc
     %dir %{python3_sitelib}/%{name}/
     %{python3_sitelib}/%{name}/__init__.py
     %{python3_sitelib}/%{name}/__pycache__
    -%{python3_sitelib}/%{name}-%{version}-py%{python3_version}.egg-info
    +%{python3_sitelib}/%{name}-%{version}b0-py%{python3_version}.egg-info
     
     
     %files -n python2-bodhi-client
     %license COPYING
     %doc README.rst
     %{python2_sitelib}/%{name}/client
    -%{python2_sitelib}/%{name}_client-%{version}-py%{python2_version}.egg-info
    +%{python2_sitelib}/%{name}_client-%{version}b0-py%{python2_version}.egg-info
     
     
     %files -n python3-bodhi-client
     %license COPYING
     %doc README.rst
     %{python3_sitelib}/%{name}/client
    -%{python3_sitelib}/%{name}_client-%{version}-py%{python3_version}.egg-info
    +%{python3_sitelib}/%{name}_client-%{version}b0-py%{python3_version}.egg-info
     
     
     %files server
    @@ -392,7 +400,7 @@ rm .coveragerc
     %config(noreplace) %{_sysconfdir}/fedmsg.d/*
     %dir %{_sysconfdir}/bodhi/
     %{python3_sitelib}/%{name}/server
    -%{python3_sitelib}/%{name}_server-%{version}-py%{python3_version}.egg-info
    +%{python3_sitelib}/%{name}_server-%{version}b0-py%{python3_version}.egg-info
     %{_mandir}/man1/bodhi-*.1*
     %{_mandir}/man1/initialize_bodhi_db.1*
     %attr(-,bodhi,root) %{_datadir}/%{name}
    @@ -406,6 +414,10 @@ rm .coveragerc
     
     
     %changelog
    +* Fri Jan 11 2019 Randy Barlow <bowlofeggs@fedoraproject.org> - 3.13.0-0.0.beta.e0ca5bc
    +- Update to 3.13.0.
    +- https://github.com/fedora-infra/bodhi/releases/tag/3.13.0
    +
     * Mon Dec 17 2018 Randy Barlow <bowlofeggs@fedoraproject.org> - 3.12.0-100
     - Upgrade to 3.12.0.
     - https://github.com/fedora-infra/bodhi/releases/tag/3.12.0
    $ cat 0000-Set-the-version-to-beta-0.patch 
    From 77f54fee023fcbfb06f7e72b3b993d39f7678efa Mon Sep 17 00:00:00 2001
    From: Randy Barlow <randy@electronsweatshop.com>
    Date: Fri, 11 Jan 2019 09:19:47 -0500
    Subject: [PATCH] Set the version to beta 0.
 
    Signed-off-by: Randy Barlow <randy@electronsweatshop.com>
    ---
     docs/conf.py | 2 +-
     setup.py     | 2 +-
     2 files changed, 2 insertions(+), 2 deletions(-)
 
    diff --git a/docs/conf.py b/docs/conf.py
    index 59edc0a8..1ba87387 100644
    --- a/docs/conf.py
    +++ b/docs/conf.py
    @@ -63,7 +63,7 @@ copyright = u'2007-{}, Red Hat, Inc.'.format(datetime.datetime.utcnow().year)
     # The short X.Y version.
     version = '3.13'
     # The full version, including alpha/beta/rc tags.
    -release = '3.13.0'
    +release = '3.13.0b0'
     
     # The language for content autogenerated by Sphinx. Refer to documentation
     # for a list of supported languages.
    diff --git a/setup.py b/setup.py
    index 44566ff5..74297bb5 100644
    --- a/setup.py
    +++ b/setup.py
    @@ -42,7 +42,7 @@ def get_requirements(requirements_file='requirements.txt'):
     
     here = os.path.abspath(os.path.dirname(__file__))
     README = open(os.path.join(here, 'README.rst')).read()
    -VERSION = '3.13.0'
    +VERSION = '3.13.0b0'
     # Possible options are at https://pypi.python.org/pypi?%3Aaction=list_classifiers
     CLASSIFIERS = [
 	'Development Status :: 5 - Production/Stable',
    -- 
    2.20.1

#. Perform any other spec file alterations that might be needed for this release (such as adding or
   removing dependencies).
#. Build the beta for Fedora Infrastructure's staging repository. At the time of writing, Bodhi runs
   on Fedora 29, so here's an example of building for the f29-infra-stg repository::

    $ rpmbuild --define "dist .fc29.infra" -bs bodhi.spec 
    Wrote: /home/bowlofeggs/rpmbuild/SRPMS/bodhi-3.13.0-0.0.beta.e0ca5bc.fc29.src.rpm
    $ koji build f29-infra /home/bowlofeggs/rpmbuild/SRPMS/bodhi-3.13.0-0.0.beta.e0ca5bc.fc29.src.rpm

#. Build the beta for bowlofegg's bodhi-pre-release Copr repository::

   $ copr build bowlofeggs/bodhi-pre-release /home/bowlofeggs/rpmbuild/SRPMS/bodhi-3.13.0-0.0.beta.e0ca5bc.fc29.src.rpm

#. It's a good idea to also do a scratch build against Fedora Rawhide just to make sure things build
   there::

   $ koji build --scratch rawhide /home/bowlofeggs/rpmbuild/SRPMS/bodhi-3.13.0-0.0.beta.e0ca5bc.fc29.src.rpm


Deploy the beta to staging
--------------------------

To deploy to beta to staging, read the `Fedora Infrastructure Bodhi SOP`_.

Notify people that the beta has been deployed so they can test and provide feedback.
You can notify the tickets that are referenced in the release notes, Fedora IRC channels (
``#bodhi``, ``#fedora-admin``, ``#fedora-apps``, ``#fedora-devel``, ``#fedora-releng``, and
``#fedora-qa``), and the Fedora infrastructure mailing list.


Test the beta
-------------

Testing beta builds in staging can be a bit tricky. One problem you may encounter is that the
staging Koji instance doesn't have all the data from production, and its database most likely wasn't
synchronized with production data at the same time that Bodhi's database was. The latter means that
Bodhi may reference some data that isn't in the staging Koji database. To overcome this problem,
I've found it to be best to make a fresh build of a package in the staging Koji database so I can be
sure that Koji has the RPM and that Bodhi can be synchronized with Koji about the resulting update.

I personally update with a small package that I have ACLs on called `python-rpdb`_. I usually just
bump the release on it and make another build, being careful to do this in the staging git
repository and not production. Then I make an update in staging Bodhi with that build and do my
testing from there. I don't do extremely extensive testing, since that is what our unit and
integration tests are for.

One test I recommend, however, is to run a compose with the newly minted update. At the time of this
writing, our integration test suite does not test integration with Koji or Pungi, and this is a
critical function of Bodhi. To do this, you will need to run ``bodhi-push`` on
``bodhi-backend01.stg.fedoraproject.org``. As an example, if I had built a test update for
``python-rpdb-2.3-3.fc29`` and I wanted to compose it, I would run this::

   $ sudo -u apache bodhi-push --builds python-rpdb-2.3-3.fc29

.. note:: We limit to just the build we built for testing here, because a full compose will fail due
          to the issues described earlier between staging and production Koji.

Of course, if you find issues during testing you should fix those issues upstream and produce a new
beta and test again.


Release Bodhi upstream
----------------------

Once you are satisfied with the quality of the beta and the beta has been in staging for a while (a
week is typical) to give people time to test and provide feedback, it is time to make a release.

We start by checking out the branch we want to make a release on, and we use ``git tag`` to create a
tag. Be sure to use the -s flag to sign the commit with your GPG key::

   $ git tag -s 3.13.0

Your ``$EDITOR`` will be opened for you to write the release notes into the tag. You can copy the
release notes into there, and I typically change the format from RST to markdown for this because
it's a little easier to read in plain text, and we will also paste the release notes into GitHub in
a bit and it'll be useful to have a markdown version anyway. You don't need to use markdown if you
prefer not to, it's just a suggestion.

.. note:: If you do use markdown in the git tag notes, don't use the ``#`` character to specify
          headings because git will interpret those lines as comments.

Push the tag up to GitHub::

   $ git push origin --tags

Now go to the releases page in GitHub, click the tags submenu, find the tag you just made, click the
"..."'s next to it, and choose "Create release". I usually just make the title along the lines of
"Bodhi 3.13.0 released". It'd be nice if GitHub used the tag message you just wrote in git, but it
does not. Fortunately, you might have just formatting it with markdown anyway and can copy and paste
it into the GitHub release notes::

   $ git show 3.13.0


.. _semantic versioning: https://semver.org
.. _Mergify: https://mergify.io
.. _patch backporting feature: https://doc.mergify.io/actions.html#backport
.. _Fedora Rawhide spec file: https://src.fedoraproject.org/rpms/bodhi/blob/master/f/bodhi.spec
.. _Fedora Infrastructure repositories: https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sops/infra-repo.html
.. _Fedora's staging instance: https://bodhi.stg.fedoraproject.org
.. _Fedora Infrastructure Bodhi SOP: https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sops/bodhi.html#performing-a-bodhi-upgrade
.. _python-rpdb: https://src.stg.fedoraproject.org/rpms/python-rpdb
