You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains the workflow required to make a `PyBaMM` release on GitHub, PyPI, and conda-forge by the maintainers.
3
+
This file contains the workflow required to make a `PyBaMM` release on
4
+
GitHub, PyPI, and conda-forge by the maintainers.
4
5
5
-
## rc0 releases (automated)
6
+
## Initial release (automated)
6
7
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
+
1. The `update_version.yml` workflow will run on every 1st of January, May
9
+
and September, updating incrementing the version to `vYY.MM.0` by running
10
+
`scripts/update_version.py` in the following files:
8
11
9
12
-`pybamm/version.py`
10
13
-`docs/conf.py`
@@ -13,21 +16,27 @@ This file contains the workflow required to make a `PyBaMM` release on GitHub, P
13
16
-`vcpkg.json`
14
17
-`CHANGELOG.md`
15
18
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).
19
+
These changes will be automatically pushed to a new branch `vYY.MM`
20
+
and a PR from `vYY.MM` to `main` will be created.
17
21
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`.
22
+
2. Create a new GitHub _release_ with the tag `vYY.MM.0` from the `vYY.MM`
23
+
branch and a description copied from `CHANGELOG.md`.
19
24
20
-
3. This release will automatically trigger `publish_pypi.yml` and create a _pre-release_ on PyPI.
25
+
3. This release will automatically trigger `publish_pypi.yml` and create a
26
+
_release_ on PyPI.
21
27
22
-
## rcX releases (manual)
28
+
## Bug fix releases (manual)
23
29
24
-
If a new release candidate is required after the release of `rc{X-1}` -
30
+
If a new release is required after the release of `vYY.MM.{x-1}` -
25
31
26
-
1.Cherry-pick the bug fix (no new features should be added to `vYY.MM` once `rc{X-1}` is released) commit to `vYY.MM` branch once the fix is merged into `develop`. The CHANGELOG entry for such fixes should go under the `rc{X-1}`heading in `CHANGELOG.md`
32
+
1.Create a new branch for the `vYY.MM.x` release using the `vYY.MM.{x-1}`tag.
27
33
28
-
2. Run `update_version.yml` manually while using `append_to_tag` to specify the release candidate version number (`rc1`, `rc2`, ...).
34
+
2. Cherry-pick the bug fixes to `vYY.MM.x` branch once the fix is
35
+
merged into `develop`. The CHANGELOG entry for such fixes should go under the
36
+
`YY.MM.x` heading in `CHANGELOG.md`
29
37
30
-
3. This will increment the version to `vYY.MMrcX` by running `scripts/update_version.py` in the following files -
38
+
3. Run `scripts/update_version.py` manually while setting `VERSION=vYY.MM.x`
39
+
in your environment. This will update the version in the following files:
31
40
32
41
-`pybamm/version.py`
33
42
-`docs/conf.py`
@@ -36,45 +45,41 @@ If a new release candidate is required after the release of `rc{X-1}` -
36
45
-`vcpkg.json`
37
46
-`CHANGELOG.md`
38
47
39
-
These changes will be automatically pushed to the existing `vYY.MM`branch and a PR will be created to update version strings in `develop`.
48
+
Commit the changes to your release branch.
40
49
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`.
50
+
4. Create a PR for the release and configure it to merge into the `main` branch.
42
51
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
-
-`pyproject.toml`
57
-
-`vcpkg.json`
58
-
-`CHANGELOG.md`
59
-
60
-
These changes will be automatically pushed to the existing `vYY.MM` branch and a PR will be created to update version strings in `develop`.
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.
52
+
5. Create a new GitHub release with the same tag (`YY.MM.x`) from the `main`
53
+
branch and a description copied from `CHANGELOG.md`. This release will
54
+
automatically trigger `publish_pypi.yml` and create a _release_ on PyPI.
67
55
68
56
## Other checks
69
57
70
58
Some other essential things to check throughout the release process -
71
59
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 `pyproject.toml`, fixing any bugs that arise
74
-
- 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 -
75
-
```
76
-
git tag -f <tag_name> <commit_hash>
77
-
git push -f <pybamm-team/PyBaMM_remote_name> <tag_name> # can only be carried out by the maintainers
78
-
```
79
-
- If changes are made to the API, console scripts, entry points, new optional dependencies are added, support for major Python versions is dropped or added, or core project information and metadata are modified at the time of the release, make sure to update the `meta.yaml` file in the `recipe/` folder of the [conda-forge/pybamm-feedstock](https://github.com/conda-forge/pybamm-feedstock) repository accordingly by following the instructions in the [conda-forge documentation](https://conda-forge.org/docs/maintainer/updating_pkgs.html#updating-the-feedstock-repository) and re-rendering the recipe
80
-
- The conda-forge release workflow will automatically be triggered following a stable PyPI release, and the aforementioned updates should be carried out directly in the main repository by pushing changes to the automated PR created by the conda-forge-bot. A manual PR can also be created if the updates are not included in the automated PR for some reason. This manual PR **must** bump the build number in `meta.yaml` and **must** be from a personal fork of the repository.
60
+
- If updating our custom vcpkg registry entries
61
+
[sundials-vcpkg-registry][SUNDIALS_VCPKG]
62
+
or [casadi-vcpkg-registry][CASADI_VCPKG] (used to build Windows
63
+
wheels), make sure to update the baseline of the registries in
64
+
vcpkg-configuration.json to the latest commit id.
65
+
- Update jax and jaxlib to the latest version in `pybamm.util` and
66
+
`pyproject.toml`, fixing any bugs that arise.
67
+
- If changes are made to the API, console scripts, entry points, new optional
68
+
dependencies are added, support for major Python versions is dropped or
69
+
added, or core project information and metadata are modified at the time
70
+
of the release, make sure to update the `meta.yaml` file in the `recipe/`
71
+
folder of the [pybamm-feedstock][PYBAMM_FEED] repository accordingly by
72
+
following the instructions in the [conda-forge documentation][FEED_GUIDE] and
73
+
re-rendering the recipe.
74
+
- The conda-forge release workflow will automatically be triggered following
75
+
a stable PyPI release, and the aforementioned updates should be carried
76
+
out directly in the main repository by pushing changes to the automated PR
77
+
created by the conda-forge-bot. A manual PR can also be created if the
78
+
updates are not included in the automated PR for some reason. This manual
79
+
PR **must** bump the build number in `meta.yaml` and **must** be from a
0 commit comments