|
1 | 1 | # Releasing |
2 | 2 |
|
3 | | -_First create a prerelease to verify the relase infrastructure_ |
| 3 | +Our build system automatically compiles and attaches cross-platform binaries to any git tag named `vX.Y.Z`. The automated changelog is generated from commit messages starting with “Merge pull request …” that landed between this tag and the previous one (as determined topologically by git). |
4 | 4 |
|
5 | | -1. `git tag v1.2.3-pre` |
6 | | -2. `git push origin v1.2.3-pre` |
7 | | -3. Wait several minutes for the build to run <https://github.com/cli/cli/actions> |
8 | | -4. Verify the prerelease succeeded and has the correct artifacts at <https://github.com/cli/cli/releases> |
| 5 | +Users who run official builds of `gh` on their machines will get notified about the new version within a 24 hour period. |
9 | 6 |
|
10 | | -_Next create a the production release_ |
| 7 | +To test out the build system, publish a prerelease tag with a name such as `vX.Y.Z-pre.0` or `vX.Y.Z-rc.1`. Note that such a release will still be public, but it will be marked as a "prerelease", meaning that it will never show up as a "latest" release nor trigger upgrade notifications for users. |
11 | 8 |
|
12 | | -5. `git tag v1.2.3` |
13 | | -6. `git push origin v1.2.3` |
14 | | -7. Wait several minutes for the build to run <https://github.com/cli/cli/actions> |
15 | | -8. Check <https://github.com/cli/cli/releases> |
16 | | -9. Verify the marketing site was updated https://cli.github.com/ |
17 | | -10. Delete the prerelease on GitHub <https://github.com/cli/cli/releases> |
| 9 | +## General guidelines |
| 10 | + |
| 11 | +* Features to be released should be reviewed and approved at least one day prior to the release. |
| 12 | +* Feature releases should bump up the minor version number. |
| 13 | + |
| 14 | +## Tagging a new release |
| 15 | + |
| 16 | +1. `git tag v1.2.3 && git push origin v1.2.3` |
| 17 | +2. Wait several minutes for builds to run: <https://github.com/cli/cli/actions> |
| 18 | +3. Check <https://github.com/cli/cli/releases> |
| 19 | +4. Scan generated release notes and optionally add a human touch by grouping items under topic sections |
| 20 | +5. Verify the marketing site was updated: <https://cli.github.com> |
| 21 | +6. (Optional) Delete any pre-releases related to this release. |
| 22 | + |
| 23 | +A successful build will result in changes across several repositories: |
| 24 | +* <https://github.com/github/cli.github.com> |
| 25 | +* <https://github.com/github/homebrew-gh> |
| 26 | +* <https://github.com/Homebrew/homebrew-core/pulls> |
| 27 | +* <https://github.com/cli/scoop-gh> |
| 28 | + |
| 29 | +If the build fails, there is not a clean way to re-run it. The easiest way would be to start over by deleting the partial release on GitHub and re-publishing the tag. Note that this might be disruptive to users or tooling that were already notified about an upgrade. If a functional release and its binaries are already out there, it might be better to try to manually fix up only the specific workflow tasks that failed. Use your best judgement depending on the failure type. |
18 | 30 |
|
19 | 31 | ## Release locally for debugging |
20 | 32 |
|
21 | 33 | A local release can be created for testing without creating anything official on the release page. |
22 | 34 |
|
| 35 | +0. Make sure GoReleaser is installed: `brew install goreleaser` |
23 | 36 | 1. `goreleaser --skip-validate --skip-publish --rm-dist` |
24 | | -2. Check and test files in `dist/` |
| 37 | +2. Find the built products under `dist/`. |
0 commit comments