|
| 1 | +# Release workflow |
| 2 | + |
| 3 | +This file contains the workflow required to make a `PyBaMM` release on GitHub and PyPI by the maintainers. |
| 4 | + |
| 5 | +## rc0 releases (automated) |
| 6 | + |
| 7 | +1. The `update_version.yml` workflow will run on every 1st of January, May and September, updating incrementing the version to `vYY.MMrc0` by running `scripts/update_version.py` in the following files - |
| 8 | + |
| 9 | + - `pybamm/version.py` |
| 10 | + - `docs/conf.py` |
| 11 | + - `CITATION.cff` |
| 12 | + - `vcpkg.json` |
| 13 | + - `docs/_static/versions.json` |
| 14 | + - `CHANGELOG.md` |
| 15 | + |
| 16 | + These changes will be automatically pushed to a new branch `vYY.MM` and a PR from `vvYY.MM` to `develop` will be created (to sync the branches). |
| 17 | + |
| 18 | +2. Create a new GitHub _pre-release_ with the tag `vYY.MMrc0` from the `vYY.MM` branch and a description copied from `CHANGELOG.md`. |
| 19 | + |
| 20 | +3. This release will automatically trigger `publish_pypi.yml` and create a _pre-release_ on PyPI. |
| 21 | + |
| 22 | +## rcX releases (manual) |
| 23 | + |
| 24 | +If a new release candidate is required after the release of `rc0` - |
| 25 | + |
| 26 | +1. Fix a bug in `vYY.MM` (no new features should be added to `vYY.MM` once `rc0` is released) and `develop` individually. |
| 27 | + |
| 28 | +2. Run `update_version.yml` manually while using `append_to_tag` to specify the release candidate version number (`rc1`, `rc2`, ...). |
| 29 | + |
| 30 | +3. This will increment the version to `vYY.MMrcX` by running `scripts/update_version.py` in the following files - |
| 31 | + |
| 32 | + - `pybamm/version.py` |
| 33 | + - `docs/conf.py` |
| 34 | + - `CITATION.cff` |
| 35 | + - `vcpkg.json` |
| 36 | + - `docs/_static/versions.json` |
| 37 | + - `CHANGELOG.md` |
| 38 | + |
| 39 | + These changes will be automatically pushed to the existing `vYY.MM` branch and a PR from `vvYY.MM` to `develop` will be created (to sync the branches). |
| 40 | + |
| 41 | +4. Create a new GitHub _pre-release_ with the same tag (`vYY.MMrcX`) from the `vYY.MM` branch and a description copied from `CHANGELOG.md`. |
| 42 | + |
| 43 | +5. This release will automatically trigger `publish_pypi.yml` and create a _pre-release_ on PyPI. |
| 44 | + |
| 45 | +## Actual release (manual) |
| 46 | + |
| 47 | +Once satisfied with the release candidates - |
| 48 | + |
| 49 | +1. Run `update_version.yml` manually, leaving the `append_to_tag` field blank ("") for an actual release. |
| 50 | + |
| 51 | +2. This will increment the version to `vYY.MMrcX` by running `scripts/update_version.py` in the following files - |
| 52 | + |
| 53 | + - `pybamm/version.py` |
| 54 | + - `docs/conf.py` |
| 55 | + - `CITATION.cff` |
| 56 | + - `vcpkg.json` |
| 57 | + - `docs/_static/versions.json` |
| 58 | + - `CHANGELOG.md` |
| 59 | + |
| 60 | + These changes will be automatically pushed to the existing `vYY.MM` branch and a PR from `vvYY.MM` to `develop` will be created (to sync the branches). |
| 61 | + |
| 62 | +3. Next, a PR from `vYY.MM` to `main` will be generated that should be merged once all the tests pass. |
| 63 | + |
| 64 | +4. Create a new GitHub _release_ with the same tag from the `main` branch and a description copied from `CHANGELOG.md`. |
| 65 | + |
| 66 | +5. This release will automatically trigger `publish_pypi.yml` and create a _release_ on PyPI. |
| 67 | + |
| 68 | +## Other checks |
| 69 | + |
| 70 | +Some other essential things to check throughout the release process - |
| 71 | + |
| 72 | +- If updating our custom vcpkg registory entries [pybamm-team/sundials-vcpkg-registry](https://github.com/pybamm-team/sundials-vcpkg-registry) or [pybamm-team/casadi-vcpkg-registry](https://github.com/pybamm-team/casadi-vcpkg-registry) (used to build Windows wheels), make sure to update the baseline of the registories in vcpkg-configuration.json to the latest commit id. |
| 73 | +- Update jax and jaxlib to the latest version in `pybamm.util` and `setup.py`, fixing any bugs that arise |
| 74 | +- Make sure the URLs in `docs/_static/versions.json` are valid |
| 75 | +- As the release workflow is initiated by the `release` event, it's important to note that the default `GITHUB_REF` used by `actions/checkout` during the checkout process will correspond to the tag created during the release process. Consequently, the workflows will consistently build PyBaMM based on the commit associated with this tag. Should new commits be introduced to the `vYY.MM` branch, such as those addressing build issues, it becomes necessary to manually update this tag to point to the most recent commit - |
| 76 | + ``` |
| 77 | + git tag -f <tag_name> <commit_hash> |
| 78 | + git push origin <tag_name> # can only be carried out by the maintainers |
| 79 | + ``` |
0 commit comments