From c60ac7d292bbd08be42c7aba41df6f48de784771 Mon Sep 17 00:00:00 2001 From: Saransh Chopra Date: Thu, 5 Oct 2023 18:06:34 +0530 Subject: [PATCH] Improve release workflow, add a note, bump version manually --- .github/release_workflow.md | 25 +++++++++++++++---------- .github/workflows/update_version.yml | 10 ++++++++++ CHANGELOG.md | 2 ++ CITATION.cff | 2 +- pybamm/version.py | 2 +- vcpkg.json | 2 +- 6 files changed, 30 insertions(+), 13 deletions(-) diff --git a/.github/release_workflow.md b/.github/release_workflow.md index 04f0667773..1af23fca25 100644 --- a/.github/release_workflow.md +++ b/.github/release_workflow.md @@ -4,7 +4,7 @@ This file contains the workflow required to make a `PyBaMM` release on GitHub an ## rc0 releases (automated) -1. The `update_version.yml` workflow will run on every 1st of January, May and September, updating incrementing the version to `YY.MMrc0` by running `scripts/update_version.py` in the following files - +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 - - `pybamm/version.py` - `docs/conf.py` @@ -13,9 +13,9 @@ This file contains the workflow required to make a `PyBaMM` release on GitHub an - `docs/_static/versions.json` - `CHANGELOG.md` - These changes will be automatically pushed to a new branch `YY.MM`. + 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). -2. Create a new GitHub _pre-release_ with the tag `YY.MMrc0` from the `YY.MM` branch and a description copied from `CHANGELOG.md`. +2. Create a new GitHub _pre-release_ with the tag `vYY.MMrc0` from the `vYY.MM` branch and a description copied from `CHANGELOG.md`. 3. This release will automatically trigger `publish_pypi.yml` and create a _pre-release_ on PyPI. @@ -23,11 +23,11 @@ This file contains the workflow required to make a `PyBaMM` release on GitHub an If a new release candidate is required after the release of `rc0` - -1. Fix a bug in `YY.MM` (no new features should be added to `YY.MM` once `rc0` is released) and `develop` individually. +1. Fix a bug in `vYY.MM` (no new features should be added to `vYY.MM` once `rc0` is released) and `develop` individually. 2. Run `update_version.yml` manually while using `append_to_tag` to specify the release candidate version number (`rc1`, `rc2`, ...). -3. This will increment the version to `YY.MMrcX` by running `scripts/update_version.py` in the following files - +3. This will increment the version to `vYY.MMrcX` by running `scripts/update_version.py` in the following files - - `pybamm/version.py` - `docs/conf.py` @@ -36,9 +36,9 @@ If a new release candidate is required after the release of `rc0` - - `docs/_static/versions.json` - `CHANGELOG.md` - These changes will be automatically pushed to the existing branch `YY.MM`. + 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). -4. Create a new GitHub _pre-release_ with the same tag (`YY.MMrcX`) from the `YY.MM` branch and a description copied from `CHANGELOG.md`. +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`. 5. This release will automatically trigger `publish_pypi.yml` and create a _pre-release_ on PyPI. @@ -48,7 +48,7 @@ Once satisfied with the release candidates - 1. Run `update_version.yml` manually, leaving the `append_to_tag` field blank ("") for an actual release. -2. This will increment the version to `YY.MMrcX` by running `scripts/update_version.py` in the following files - +2. This will increment the version to `vYY.MMrcX` by running `scripts/update_version.py` in the following files - - `pybamm/version.py` - `docs/conf.py` @@ -57,9 +57,9 @@ Once satisfied with the release candidates - - `docs/_static/versions.json` - `CHANGELOG.md` - These changes will be automatically pushed to the existing branch `YY.MM`. + 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). -3. Next, a PR from `YY.MM` to `main` will be generated that should be merged once all the tests pass. +3. Next, a PR from `vYY.MM` to `main` will be generated that should be merged once all the tests pass. 4. Create a new GitHub _release_ with the same tag from the `main` branch and a description copied from `CHANGELOG.md`. @@ -72,3 +72,8 @@ Some other essential things to check throughout the release process - - 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. - Update jax and jaxlib to the latest version in `pybamm.util` and `setup.py`, fixing any bugs that arise - Make sure the URLs in `docs/_static/versions.json` are valid +- 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 - + ``` + git tag -f + git push origin # can only be carried out by the maintainers + ``` diff --git a/.github/workflows/update_version.yml b/.github/workflows/update_version.yml index 472de06f0e..0d63e68007 100644 --- a/.github/workflows/update_version.yml +++ b/.github/workflows/update_version.yml @@ -63,7 +63,17 @@ jobs: with: message: 'Bump to ${{ env.VERSION }}' + - name: Make a PR from ${{ env.NON_RC_VERSION }} to develop + uses: repo-sync/pull-request@v2 + with: + source_branch: '${{ env.NON_RC_VERSION }}' + destination_branch: "develop" + pr_title: "Sync ${{ env.NON_RC_VERSION }} and develop" + pr_body: "**Merge as soon as possible to avoid potential conflicts.**" + github_token: ${{ secrets.GITHUB_TOKEN }} + - name: Make a PR from ${{ env.NON_RC_VERSION }} to main + id: release_pr if: github.event_name == 'workflow_dispatch' && !startsWith(github.event.inputs.append_to_tag, 'rc') uses: repo-sync/pull-request@v2 with: diff --git a/CHANGELOG.md b/CHANGELOG.md index c400cc31ea..a8518ba639 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,7 @@ # [Unreleased](https://github.com/pybamm-team/PyBaMM/) +# [v23.9rc0](https://github.com/pybamm-team/PyBaMM/tree/v23.9rc0) - 2023-10-31 + ## Features - The parameter "Ambient temperature [K]" can now be given as a function of position `(y,z)` and time `t`. The "edge" and "current collector" heat transfer coefficient parameters can also depend on `(y,z)` ([#3257](https://github.com/pybamm-team/PyBaMM/pull/3257)) - Spherical and cylindrical shell domains can now be solved with any boundary conditions ([#3237](https://github.com/pybamm-team/PyBaMM/pull/3237)) diff --git a/CITATION.cff b/CITATION.cff index f5d6fe4911..5a9e1e2ddc 100644 --- a/CITATION.cff +++ b/CITATION.cff @@ -24,6 +24,6 @@ keywords: - "expression tree" - "python" - "symbolic differentiation" -version: "23.5" +version: "23.9rc0" repository-code: "https://github.com/pybamm-team/PyBaMM" title: "Python Battery Mathematical Modelling (PyBaMM)" diff --git a/pybamm/version.py b/pybamm/version.py index 0e8c575aea..c8d63f83e1 100644 --- a/pybamm/version.py +++ b/pybamm/version.py @@ -1 +1 @@ -__version__ = "23.5" +__version__ = "23.9rc0" diff --git a/vcpkg.json b/vcpkg.json index 2609370382..6877dfa094 100644 --- a/vcpkg.json +++ b/vcpkg.json @@ -1,6 +1,6 @@ { "name": "pybamm", - "version-string": "23.5", + "version-string": "23.9rc0", "dependencies": [ "casadi", {