Skip to content

Latest commit

 

History

History
65 lines (40 loc) · 4.73 KB

ReleaseGuide.md

File metadata and controls

65 lines (40 loc) · 4.73 KB

Guide to release new version of python-bindings

The developer who is releasing a new version of the python-bindings is expected to follow this work flow:

The release of the python-bindings repository is made directly from a release branch called python-bindings-v2.1.1.1. This branch is mainly needed to help other developers with testing.

  1. Create a branch called python-bindings-v2.1.1.1 from the latest commit of the develop branch.

  2. Open a Pull Request master <-- python-bindings-v2.1.1.1 named after the version (i.e. Release v2.1.1.1) and briefly describe the new features of the release in the PR description.

  3. Bump the version in the following places:

    • CHANGELOG.md on python-bindings-v2.1.1.1.
    • There is no need to bump the version anywhere else, since we use the python-versioneer for maintaining the version everywhere else.

  4. Optional test the py-pyprecice Spack package using spack dev-build py-pyprecice@develop.

  5. Draft a New Release in the Releases section of the repository page in a web browser.

    • The release tag needs to be the exact version number (i.e.v2.1.1.1 or v2.1.1.1rc1, compare to existing tags).
    • If this is a stable release, use @target:master. If this is a pre-release, use @target:python-bindings-v2.1.1.1. If you are making a pre-release, directly skip to the pre-release section below.
    • Release title is also the version number (i.e. v2.1.1.1 or v2.1.1.1rc1, compare to existing releases).

  6. As soon as one approving review is made, merge the release PR (from python-bindings-v2.1.1.1) into master.

  7. Merge master into develop for synchronization of develop.

  8. If everything is in order up to this point then the new version can be released by hitting the "Publish release" button in your release Draft. This will create the corresponding tag and trigger publishing the release to PyPI.

  9. Now there exists be a tag corresponding to the release on master. Re-run the docker release workflow build-docker.yml via dispatch such that the correct version is picked up by versioneer. Check the version in the container via docker pull precice/python-bindings, then docker run -ti precice/python-bindings, and inside the container $ python3 -c "import precice; print(precice.__version__)". ⚠️ There is an open issue that needs fixing #195 ⚠️

  10. Add an empty commit (details #109) on master by running the steps:

    git checkout master
git commit --allow-empty -m "post-tag bump"
git push

    Check that everything is in order via git log. Important: The tag and origin/master should not point to the same commit. For example:

    commit 44b715dde4e3194fa69e61045089ca4ec6925fe3 (HEAD -> master, origin/master)
Author: Benjamin Rodenberg <[email protected]>
Date:   Wed Oct 20 10:52:41 2021 +0200

    post-tag bump

commit d2645cc51f84ad5eda43b9c673400aada8e1505a (tag: v2.3.0.1)
Merge: 2039557 aca2354
Author: Benjamin Rodenberg <[email protected]>
Date:   Tue Oct 19 12:57:24 2021 +0200

    Merge pull request #132 from precice/python-bindings-v2.3.0.1

    Release v2.3.0.1

    For more details refer to #109 and python-versioneer/python-versioneer#217.

  11. Temporarily not maintained Update the py-pyprecice Spack package.

Pre-release

After creating the branch and drafting a release, directly hit the "Publish release" button in your Release Draft. Please note that the release branch is not merged into the master branch during a pre-release. Merging is done only for the stable release. You can check the pre-release artifacts (e.g. release on PyPI) of the release. No further action is required for a pre-release.