Releasing small batches often is backed by research 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.
- Release versions follow semantic versioning
- Releases are associated with signed, annotated git tags1.
- Release notes are automatically generated2.
v1 branch, the current version is always
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
v2.4.7... that contains only bug fixes, the next version
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. The remaining steps require human intervention through the GitHub web view although automated solutions exist that may be adopted in the future.
- Open the the new release page
- At the top of the form, click on the
Choose a tagselect control and select
- In the
Writetab below, click the
Auto-generate release notesbutton
- At the bottom of the form, click the
- you're done!
This was not always true. There are many lightweight git tags present in the repository history. ↩
This was not always true. The
docs/CHANGELOG.mddocument 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. ↩