|
|
|
|
# Releasing urfave/cli
|
|
|
|
|
|
|
|
|
|
Releasing small batches often is [backed by
|
|
|
|
|
research](https://itrevolution.com/accelerate-book/) as part of the
|
|
|
|
|
virtuous cycles that keep teams and products healthy.
|
|
|
|
|
|
|
|
|
|
To that end, the overall goal of the release process is to send
|
|
|
|
|
changes out into the world as close to the time the commits were
|
|
|
|
|
merged to the `main` branch as possible. In this way, the community
|
|
|
|
|
of humans depending on this library are able to make use of the
|
|
|
|
|
changes they need **quickly**, which means they shouldn't have to
|
|
|
|
|
maintain long-lived forks of the project, which means they can get
|
|
|
|
|
back to focusing on the work on which they want to focus. This also
|
|
|
|
|
means that the @urfave/cli team should be able to focus on
|
|
|
|
|
delivering a steadily improving product with significantly eased
|
|
|
|
|
ability to associate bugs and regressions with specific releases.
|
|
|
|
|
|
|
|
|
|
## Process
|
|
|
|
|
|
|
|
|
|
- Release versions follow [semantic versioning](https://semver.org/)
|
|
|
|
|
- Releases are associated with **signed, annotated git tags**[^1].
|
|
|
|
|
- Release notes are **automatically generated**[^2].
|
|
|
|
|
|
|
|
|
|
In the `main` or `v1` branch, the current version is always
|
|
|
|
|
available via:
|
|
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
git describe --always --dirty --tags
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
**NOTE**: if the version reported contains `-dirty`, this is
|
|
|
|
|
indicative of a "dirty" work tree, which is not a great state for
|
|
|
|
|
creating a new release tag. Seek help from @urfave/cli teammates.
|
|
|
|
|
|
|
|
|
|
For example, given a described version of `v2.4.7-3-g68da1cd` and a
|
|
|
|
|
diff of `v2.4.7...` that contains only bug fixes, the next version
|
|
|
|
|
should be `v2.4.8`:
|
|
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
git tag -a -s -m 'Release 2.4.8' v2.4.8
|
|
|
|
|
git push origin v2.4.8
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
The tag push will trigger a GitHub Actions workflow and will be
|
|
|
|
|
**immediately available** to the [Go module mirror, index, and
|
|
|
|
|
checksum database](https://proxy.golang.org/). The remaining steps
|
|
|
|
|
require human intervention through the GitHub web view although
|
|
|
|
|
[automated solutions
|
|
|
|
|
exist](https://github.com/softprops/action-gh-release) that may be
|
|
|
|
|
adopted in the future.
|
|
|
|
|
|
|
|
|
|
- Open the [the new release page](https://github.com/urfave/cli/releases/new)
|
|
|
|
|
- At the top of the form, click on the `Choose a tag` select control and select `v2.4.8`
|
|
|
|
|
- In the `Write` tab below, click the `Auto-generate release notes` button
|
|
|
|
|
- At the bottom of the form, click the `Publish release` button
|
|
|
|
|
- :white_check_mark: you're done!
|
|
|
|
|
|
|
|
|
|
[^1]: This was not always true. There are many **lightweight git
|
|
|
|
|
tags** present in the repository history.
|
|
|
|
|
|
|
|
|
|
[^2]: This was not always true. The
|
|
|
|
|
[`docs/CHANGELOG.md`](./CHANGELOG.md) document used to be
|
|
|
|
|
manually maintained. Relying on the automatic release notes
|
|
|
|
|
generation requires the use of **merge commits** as opposed to
|
|
|
|
|
squash merging or rebase merging.
|
