From 65c7203a3e86c395a2cbba40c2920c089ace9498 Mon Sep 17 00:00:00 2001 From: Bracken Dawson Date: Fri, 9 Feb 2024 14:10:50 +0000 Subject: [PATCH 1/2] Prepare for v1.8.0 --- gimme | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gimme b/gimme index ca75944..d984db8 100755 --- a/gimme +++ b/gimme @@ -55,7 +55,7 @@ set -o pipefail [[ ${GIMME_DEBUG} ]] && set -x -readonly GIMME_VERSION="v1.7.1" +readonly GIMME_VERSION="v1.8.0" readonly GIMME_COPYRIGHT="Copyright (c) 2022 gimme contributors" readonly GIMME_LICENSE_URL="https://raw.githubusercontent.com/urfave/gimme/${GIMME_VERSION}/LICENSE" export GIMME_VERSION From 8485121135a6bd340b42e1a3e8df64f2036f3ebd Mon Sep 17 00:00:00 2001 From: Bracken Dawson Date: Fri, 9 Feb 2024 14:31:37 +0000 Subject: [PATCH 2/2] Document release process Based on urfave/cli and this conversation: https://github.com/urfave/gimme/pull/23#issuecomment-1304032618 --- docs/RELEASING.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 docs/RELEASING.md diff --git a/docs/RELEASING.md b/docs/RELEASING.md new file mode 100644 index 0000000..30efadc --- /dev/null +++ b/docs/RELEASING.md @@ -0,0 +1,55 @@ +# Releasing urfave/gimme + +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/gimme 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**[^1]. + +In the `main` or `v2-maint` 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/gimme teammates. + +For example, given a described version of `v1.7.1-7-g65c7203` and a +diff of `v1.7.1...` that contains only bug fixes, the next version +should be `v1.7.2`: + +- Update `GIMME_VERSION` in [gimme](https://github.com/urfave/gimme/blob/main/gimme) via pull request. + +- Once that is approved and merged make a tag locally: +```sh +TAG_VERSION=v1.7.2 make tag +git push origin v1.7.2 +``` + +- Open the [the new release page](https://github.com/urfave/gimme/releases/new) +- At the top of the form, click on the `Choose a tag` select control and select `v1.7.2` +- 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. And releases with the wrong version + number in source code.