-
Notifications
You must be signed in to change notification settings - Fork 47
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix
upload-release-asset
steps in assets.yml
.
Update `RELEASE.md`, removing references to conda. Update `CHANGELOG.md`. Update version to 0.12.1.
- Loading branch information
Showing
4 changed files
with
71 additions
and
59 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,58 +1,52 @@ | ||
Release procedure | ||
================= | ||
|
||
Most of the release process is managed by GitHub Actions. If you follow the | ||
procedure below, it will automatically test and build all wheels and conda | ||
packages for all platform, and publish them to PyPI and conda assuming the | ||
secrets are configured correctly. | ||
Most of the release process is managed by GitHub Actions. If you follow the procedure below, | ||
it will automatically test and build all wheels for all platforms, | ||
and publish them to PyPI assuming the secrets are configured correctly. | ||
|
||
- Make a branch with a name starting with "release" based upon the commit that | ||
is to be released. For example, `release-0.0.1`, but the suffix doesn't | ||
matter. | ||
- Make a branch with a name starting with "release" based upon the commit that is to be released. | ||
For example, `release-0.0.1`, but the suffix doesn't matter. | ||
|
||
- Change the version in `include/ql/version.h` (this is the only functional | ||
place where the version is hardcoded) and change any other files where | ||
applicable (changelog, etc) and update `CHANGELOG.md` accordingly, then | ||
commit and make a PR for it. | ||
- Change the version in `include/ql/version.h` (this is the only functional place where the version is hardcoded) | ||
and change any other files where applicable (`CHANGELOG.md`, etc.), then commit and make a PR for it. | ||
|
||
- CI will now run not only the test workflow, but also the assets workflow. | ||
The assets workflow builds the wheels and conda packages, but publishes them | ||
to the GitHub Actions build artifacts only. You can then test these yourself | ||
if you have reason to believe that something might be wrong with them that | ||
CI might not catch. To find them, go to Actions -> Assets workflow -> | ||
click the run for your branch -> Artifacts. | ||
The assets workflow builds the wheels, but publishes them to the GitHub Actions build artifacts only. | ||
You can then test these yourself if you have reason to believe that | ||
something might be wrong with them that CI might not catch. | ||
To find them, go to Actions -> Assets workflow -> click the run for your branch -> Artifacts. | ||
|
||
- Always delete the artifacts of the assets runs when you're done with them | ||
or don't need them! OpenQL's binaries are quite big, so if you don't do | ||
this, GitHub will soon start rejecting new artifacts due to storage quota. | ||
- Always delete the artifacts of the assets runs when you're done with them or don't need them! | ||
OpenQL's binaries are quite big, so if you don't do this, | ||
GitHub will soon start rejecting new artifacts due to storage quota. | ||
|
||
- If the test or assets workflows fail, fix it before merging the PR (of | ||
course). | ||
- If the test or assets workflows fail, fix it before merging the PR (of course). | ||
|
||
- Once CI is green, merge the PR into `develop` if there are any changes. | ||
If no changes were needed, just delete the branch to clean up. | ||
|
||
- If needed, also merge to `master`. | ||
- Create and push a new tag using the same version you put in `include/ql/version.h`. | ||
For example: | ||
|
||
- Draft a new release through the GitHub interface. Set the "tag version" | ||
to the same version you put in `include/ql/version.h`, the title to | ||
"Release `version`: `name`", and write release notes in the body. The | ||
release notes should include at least: | ||
``` | ||
git tag 0.0.1 | ||
git push origin 0.0.1 | ||
``` | ||
|
||
- a summary of what has changed, what is new, and what is incompatible | ||
with the previous version; | ||
- if there are incompatibilities, what the user can do for mitigation; | ||
and | ||
- Draft a new release through the GitHub interface. | ||
Set the "tag version", and the title to "Release `version`: `name`". | ||
And write release notes in the body, including at least: | ||
|
||
- a summary of what has changed, what is new, and what is incompatible with the previous version; | ||
- if there are incompatibilities, what the user can do for mitigation; and | ||
- what has been deprecated and may be removed in a later version. | ||
|
||
In principle, these things apply only to the public API. For releases that | ||
don't go to master, check the "prerelease" box, so it won't show up as the | ||
latest release. | ||
In principle, these things apply only to the public API. | ||
|
||
- CI will run the assets workflow again, now with the new version string baked | ||
into the wheels and packages. When done, these wheels and packages are | ||
automatically added to the GitHub release, and if the secrets/API keys for | ||
PyPI and conda are correct, CI will publish them there. | ||
- CI will run the assets workflow again, now with the new version string baked into the wheels. | ||
When done, these wheels are automatically added to the GitHub release, | ||
and if the secrets/API keys for PyPI are correct, CI will publish them there. | ||
|
||
- Remove the temporary `release-*` branch. Users can find particular releases | ||
via the tag that GitHub automatically added when you drafted the release. | ||
- Remove the temporary `release-*` branch. | ||
Users can find particular releases via the tag that GitHub automatically added when you drafted the release. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters