Skip to content

Latest commit

 

History

History
116 lines (76 loc) · 5.67 KB

RELEASE.md

File metadata and controls

116 lines (76 loc) · 5.67 KB

Releasing a new Heat version

These are basic instructions for internal use. Will be expanded as the need arises.

Table of Contents

Major or minor release

(e.g. 1.4 --> 1.5, or 1.5 --> 2.0)

In the following, we assume we are about to release Heat v1.5.0.

PRE-REQUISITES:

  • You need PyPi, Test.PyPi account
  • All intended PRs are merged, all tests have passed, and the main branch is ready for release.

Create Pre-release Branch

  1. Got to this GH Action and start a new manual workflow.

  2. Use workflow from should always be main.

  3. Change the version number to the next release (1.5.0) in this case.

  4. Because this is a major or minor release, the base branch should be main.

  5. Change the title, if you want to give the release a special name.

  6. Run the workflow.

When the workflow is done, you should see two new pull requests. One targeting main, the other one targeting stable. Both should be created for the same branch, pre-release/x.y.z. The new branch should include changes with the new version number on version.py, and an up-to-date CHANGELOG.md. For now, ignore the PR targeting main. That PR should only be merged after the release has been merged to stable.

  1. Ensure that the changes to version.py and CHANGELOG.md are correct, if not, fix them.

  2. If necessary, also update the Requirements section on README.md to reflect the latest version of the dependencies.

  3. Update CITATION.cff if needed, i.e. add names of non-core contributors (they are included in the Release notes draft you just created). Push to workflows/version-update.

  4. Once the changes are done, merge the pull request.

  • ONLY MERGE THE PR FOR stable
  • DO NOT DELETE THE BRANCH AFTERWARDS.
  • Remember to get a reviewers approval.
  • Wait for the tests to finish.
  • Squash and merge.

Go to the main repo page, and then to releases (right panel). There should be a draft release with the changes made by the latest release.

  1. Draft release notes:
  • Go to the GitHub repo's Releases page.
  • The release notes draft is automated. Click on Edit Draft
  • Select the new tag: v1.5.0. Modify Target branch: release/1.5.x
  • Edit release notes as needed (see older releases)
  • Click on Save but do not publish yet

  1. On your local machine, fetch all the changes from origin, checkout the stable branch.

  2. Build wheel in your local heat/ directory.

    rm -f dist/*
python -m build

    You might have to install the build package first (i.e. with conda install -c conda-forge build or pip install build)

  3. Upload to Test PyPI and verify things look right. You need to install twine first.

     twine upload -r testpypi dist/*

    twine will prompt for your username and password.

  4. When everything works, upload to PyPI:

twine upload dist/*
  1. Go back to the Release Notes draft and publish them. The new release is out!
  • Make sure the CHANGELOG.md got updated, if not, call @JuanPedroGHM.
  • Check our Zenodo page to make sure a DOI was created for the release.

  1. On branch main, we want to modify the version so that minor is increased by 1, and extension is "dev". We also want to merge any changes to the changelog, and overall make sure it is up to date with the latest release changes. That is what the second PR is for. In this example we want the version on main to be:1.6.0-dev. We go to the left over PR, and change the version number accordingly. Make sure to also fix any merge conflicts.

  2. Get approval and merge. You're done! Except if you're a conda-forge maintainer, then see conda-forge build.

Patch release

(e.g. 1.5.0 --> 1.5.1)

  1. Check that all intended branches have been merged to the stable branch.

  2. Got to this GH Action and start a new manual workflow.

  3. Use workflow from should always be main.

  4. Change the version number to the next release (1.5.1) in this case.

  5. Because this is a patch release, the base branch should be stable.

  6. Change the title, if you want to give the release a special name.

  7. Run the workflow.

When the workflow is done, you should see two new pull requests. One targeting main, the other one targeting stable. Both should be created for the same branch, pre-release/x.y.z. The new branch should include changes with the new version number on version.py, and an update CHANGELOG.md. For now, ignore the PR targeting main. That PR should only be merged after the release has been merged to stable.

  1. Follow steps 3-14 from the Major or minor release section.

conda-forge build

After releasing, the conda-forge automation will create a new PR on https://github.com/conda-forge/heat-feedstock. It's normal if this takes hours. conda-forge maintainers will review the PR and merge it if everything is correct.