Creating a New Release

Development

• Make a new milestone and assign issues/pull requests to this milestone
• As issues are dealt with and pull requests merged, they should be merged into the dev branch rather than master
• Once all issues/pull requests are closed/merged into dev for the next milestone you are ready to make a new release

GitHub Release

• Make a new branch from dev called rel\vx.y.z e.g. v3.1.4. This is the branch you're going to do all the release based modifications in
• Update changelog.MD with what features have been added, changed and fixed in this version, its helpful to refer to the milestone at this point and reference specific issues/pull requests in the changelog. Its important these notes are accurate as they will become the release notes
• Bump the version number in setup.py
• Add any new contributors, bump the version number and update the release date in CITATION.cff
• Do a final double check if anything else in readme.MD needs updating e.g. you've added a new feature that should be listed on the repos homepage
• Open a pull request from the rel\vx.y.z to master (this should be the only type of pull request merged into master i.e. there shouldn't be updates to master the don't come from a new release)
• If all tests/reviews pass, merge rel\vx.y.z into master. Be warned, the process of making a new release can involve a lot of tests running in a relatively short period of time. This can sometimes make Zenodo (the service used to host the test data) unhappy as its API doesn't like lots of requests at once. If test_fetch.py fails (especially on a different test on each Action e.g. test_ge_t2star fails on the pull request on Python 3.7 but test_siemens_dwi fails on Python 3.8 on the push) then try waiting half an hour or so, then run the tests again
• You should also merge rel\vx.y.z back into dev
• Create a tag on this merge commit with the same version number as the release e.g. v3.1.4 and push this tag to upstream (although ideally push this to all remotes)
• Creating this tag will start an Action that will generate the new release on GitHub and publish the update to PyPI

Post Release

• Close any issues/PRs from this milestone that didn't automatically close on merge
• Close the milestone and make any new milestones that you'll be working towards
• Wait a minute or so for the Release Action to finish
• Check that the new version has appeared in the releases list
• Check that the new version is available on PyPI
• Check that a new DOI has been minted on Zenodo