Merge remote-tracking branch 'origin/main' into applying-pr1218

docs/CHANGELOG.md

@@ -1,3 +1,9 @@
+> :warning: This document is no longer being actively maintained. Please see the
+> [releases page](https://github.com/urfave/cli/releases) for all release notes
+> and related hypermedia for releases `>= 1.22.5`, `>= 2.3.0`.
+
+---
+
 # Change Log
 
 **ATTN**: This project uses [semantic versioning](http://semver.org/).

docs/CONTRIBUTING.md

@@ -6,7 +6,7 @@ Feel free to put up a pull request to fix a bug or maybe add a feature. We will
 give it a code review and make sure that it does not break backwards
 compatibility. If collaborators agree that it is in line with
 the vision of the project, we will work with you to get the code into
-a mergeable state and merge it into the master branch.
+a mergeable state and merge it into the main branch.
 
 If you have contributed something significant to the project, we will most
 likely add you as a collaborator. As a collaborator you are given the ability

docs/RELEASING.md

@@ -0,0 +1,61 @@
+# 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. 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.

docs/v2/manual.md

@@ -674,8 +674,10 @@ Take for example this app that requires the `lang` flag:
 package main
 
 import (
+  "fmt"
   "log"
   "os"
+
   "github.com/urfave/cli/v2"
 )