Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add merge instructions to release instructions #3292

Merged
merged 1 commit into from
Jul 13, 2023
Merged

Add merge instructions to release instructions #3292

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 33 additions & 3 deletions doc/sphinx/source/community/release_strategy/release_strategy.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -462,7 +462,37 @@ and create the new release from the release branch (i.e. not from ``main``).
The release tag always starts with the letter ``v`` followed by the version
number, e.g. ``v2.1.0``.

6. Create and upload the PyPI package
6. Mark the release in the main branch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When the (pre-)release is tagged, it is time to merge the release branch back into `main`.
We do this for two reasons, namely, one, to mark the point up to which commits in `main`
have been considered for inclusion into the present release, and, two, to inform
setuptools-scm about the version number so that it creates the correct version number in
`main`.
However, unlike in a normal merge, we do not want to integrate any of the changes from the
release branch into main.
This is because all changes that should be in both branches, i.e. bug fixes, originate from
`main` anyway and the only other changes in the release branch relate to the release itself.
To take this into account, we perform the merge in this case on the command line using `the
ours merge strategy <https://git-scm.com/docs/merge-strategies#Documentation/merge-strategies.txt-ours-1>`__
(``git merge -s ours``), not to be confused with the ``ours`` option to the ort merge strategy
(``git merge -X ours``).
For details about merge strategies, see the above-linked page.
To execute the merge use following sequence of steps

.. code-block:: bash

git fetch
git checkout main
git pull
git merge -s ours v2.1.x
git push

Note that the release branch remains intact and you should continue any work on the release
on that branch.

7. Create and upload the PyPI package
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The package is automatically uploaded to the
Expand Down Expand Up @@ -493,7 +523,7 @@ Follow these steps to create a new Python package:
You can read more about this in
`Packaging Python Projects <https://packaging.python.org/tutorials/packaging-projects/>`__.

7. Create the Conda package
8. Create the Conda package
~~~~~~~~~~~~~~~~~~~~~~~~~~~

The ``esmvaltool`` package is published on the `conda-forge conda channel
Expand All @@ -514,7 +544,7 @@ they will merge the pull request, which will in turn publish the package on
conda-forge some time later.
Contact the feedstock maintainers if you want to become a maintainer yourself.

8. Check the Docker images
9. Check the Docker images
~~~~~~~~~~~~~~~~~~~~~~~~~~

There are three main Docker container images available for ESMValTool on
Expand Down