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
Copy file name to clipboardExpand all lines: .github/release_workflow.md
+12-11Lines changed: 12 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Release workflow
2
2
3
-
This file contains the workflow required to make a `PyBaMM` release on GitHuband PyPI by the maintainers.
3
+
This file contains the workflow required to make a `PyBaMM` release on GitHub, PyPI, and conda-forge by the maintainers.
4
4
5
5
## rc0 releases (automated)
6
6
@@ -9,8 +9,8 @@ This file contains the workflow required to make a `PyBaMM` release on GitHub an
9
9
-`pybamm/version.py`
10
10
-`docs/conf.py`
11
11
-`CITATION.cff`
12
+
-`pyproject.toml`
12
13
-`vcpkg.json`
13
-
-`docs/_static/versions.json`
14
14
-`CHANGELOG.md`
15
15
16
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).
@@ -21,9 +21,9 @@ This file contains the workflow required to make a `PyBaMM` release on GitHub an
21
21
22
22
## rcX releases (manual)
23
23
24
-
If a new release candidate is required after the release of `rc0` -
24
+
If a new release candidate is required after the release of `rc{X-1}` -
25
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.
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`
27
27
28
28
2. Run `update_version.yml` manually while using `append_to_tag` to specify the release candidate version number (`rc1`, `rc2`, ...).
29
29
@@ -32,11 +32,11 @@ If a new release candidate is required after the release of `rc0` -
32
32
-`pybamm/version.py`
33
33
-`docs/conf.py`
34
34
-`CITATION.cff`
35
+
-`pyproject.toml`
35
36
-`vcpkg.json`
36
-
-`docs/_static/versions.json`
37
37
-`CHANGELOG.md`
38
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).
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`.
40
40
41
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
42
@@ -53,11 +53,11 @@ Once satisfied with the release candidates -
53
53
-`pybamm/version.py`
54
54
-`docs/conf.py`
55
55
-`CITATION.cff`
56
+
-`pyproject.toml`
56
57
-`vcpkg.json`
57
-
-`docs/_static/versions.json`
58
58
-`CHANGELOG.md`
59
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).
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
61
62
62
3. Next, a PR from `vYY.MM` to `main` will be generated that should be merged once all the tests pass.
63
63
@@ -70,10 +70,11 @@ Once satisfied with the release candidates -
70
70
Some other essential things to check throughout the release process -
71
71
72
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
73
+
- Update jax and jaxlib to the latest version in `pybamm.util` and `pyproject.toml`, fixing any bugs that arise
75
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 -
76
75
```
77
76
git tag -f <tag_name> <commit_hash>
78
-
git push origin <tag_name> # can only be carried out by the maintainers
77
+
git push -f <pybamm-team/PyBaMM_remote_name> <tag_name> # can only be carried out by the maintainers
79
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.
0 commit comments