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
Use the bump version GitHub Actions workflow perform a dry run of the bump version to the new release tag.
Check the annotated tag in the dry run workflow logs to make sure it looks correct.
If the dry run passes as expected, run the same workflow with the dry run option set to false to bump the release tag version and push the new tag back to GitHub.
Verify the release tag was pushed to the correct branch.
Verify the release tag commit has bumped the correct versions.
Watch the CI to verify all tag based jobs finish correctly.
Verify the release for the tag on TestPyPI looks correct.
Create a GitHub release from the new release tag and copy the release notes published to the GitHub release page. The creation of the GitHub release triggers all other release related activities.
Before pasting in the release notes copy the changes that the GitHub bot has already queued up and pasted into the tag and place them in the "Changes" section of the release notes. If the release notes are published before these are copied then they will be overwritten and you'll have to add them back in by hand.
Verify there is a new Zenodo DOI minted for the release.
Verify that the new release archive metadata on Zenodo matches is being picked up as expected from CITATION.cff.
Verify that a Binder has properly built for the new release.
Watch for a GitHub notification that there is an automatic PR to the Conda-forge feedstock. This may take multiple hours to happen. If there are any changes needed to the Conda-forge release make them from a personal account and not from an organization account to have workflows properly trigger.
Check if any requirements need to be updated by commenting "@conda-grayskull show requirements" on the PR.
Verify the requirements in the Conda-forge feedstock recipe meta.yaml match those in pyproject.toml.
After Release
Verify that the release is installable from both PyPI and Conda-forge.
Send the drafted pyhf-announcements email out from the pyhf-announcements account email.
Tweet the release out on both personal and team Twitter accounts.
Make a release for the pyhf tutorial corresponding to the previous release number. This release represents the last version of the tutorial that is guaranteed to work with previous release API.
Release Checklist
Before Release
docs/release-notes
..github/ISSUE_TEMPLATE
directory if there are revisions.codemeta.json
file in the release PR if its requirements have updated.pyhf-announcements
mailing list that summarizes the main points of the release notes and circulate it for development team approval.Create Release Tag
For a video walkthrough consult the
pyhf
v0.7.1
release recording on YouTube.false
to bump the release tag version and push the new tag back to GitHub.After Release Tag Pushed To GitHub
Verify that the new release archive metadata on Zenodo matches is being picked up as expected from
CITATION.cff
.meta.yaml
match those inpyproject.toml
.After Release
pyhf-announcements
email out from thepyhf-announcements
account email.pyhf
tutorial corresponding to the previous release number. This release represents the last version of the tutorial that is guaranteed to work with previous release API.pyhf
available in the next LCG release.v0.6.3
request ticket and thev0.7.1
request ticket as examples.The text was updated successfully, but these errors were encountered: