Skip to content

Commit 56b98be

Browse files
Merge pull request #26 from urfave/prep-1.8
Prepare for v1.8.0
2 parents 75940b0 + 8485121 commit 56b98be

File tree

2 files changed

+56
-1
lines changed

2 files changed

+56
-1
lines changed

docs/RELEASING.md

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
# Releasing urfave/gimme
2+
3+
Releasing small batches often is [backed by
4+
research](https://itrevolution.com/accelerate-book/) as part of the
5+
virtuous cycles that keep teams and products healthy.
6+
7+
To that end, the overall goal of the release process is to send
8+
changes out into the world as close to the time the commits were
9+
merged to the `main` branch as possible. In this way, the community
10+
of humans depending on this library are able to make use of the
11+
changes they need **quickly**, which means they shouldn't have to
12+
maintain long-lived forks of the project, which means they can get
13+
back to focusing on the work on which they want to focus. This also
14+
means that the @urfave/gimme team should be able to focus on
15+
delivering a steadily improving product with significantly eased
16+
ability to associate bugs and regressions with specific releases.
17+
18+
## Process
19+
20+
- Release versions follow [semantic versioning](https://semver.org/)
21+
- Releases are associated with **signed, annotated git tags**[^1].
22+
- Release notes are **automatically generated**[^1].
23+
24+
In the `main` or `v2-maint` branch, the current version is always
25+
available via:
26+
27+
```sh
28+
git describe --always --dirty --tags
29+
```
30+
31+
**NOTE**: if the version reported contains `-dirty`, this is
32+
indicative of a "dirty" work tree, which is not a great state for
33+
creating a new release tag. Seek help from @urfave/gimme teammates.
34+
35+
For example, given a described version of `v1.7.1-7-g65c7203` and a
36+
diff of `v1.7.1...` that contains only bug fixes, the next version
37+
should be `v1.7.2`:
38+
39+
- Update `GIMME_VERSION` in [gimme](https://github.com/urfave/gimme/blob/main/gimme) via pull request.
40+
41+
- Once that is approved and merged make a tag locally:
42+
```sh
43+
TAG_VERSION=v1.7.2 make tag
44+
git push origin v1.7.2
45+
```
46+
47+
- Open the [the new release page](https://github.com/urfave/gimme/releases/new)
48+
- At the top of the form, click on the `Choose a tag` select control and select `v1.7.2`
49+
- In the `Write` tab below, click the `Auto-generate release notes` button
50+
- At the bottom of the form, click the `Publish release` button
51+
- :white_check_mark: you're done!
52+
53+
[^1]: This was not always true. There are many **lightweight git
54+
tags** present in the repository history. And releases with the wrong version
55+
number in source code.

gimme

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,7 @@ set -o pipefail
5555

5656
[[ ${GIMME_DEBUG} ]] && set -x
5757

58-
readonly GIMME_VERSION="v1.7.1"
58+
readonly GIMME_VERSION="v1.8.0"
5959
readonly GIMME_COPYRIGHT="Copyright (c) 2022 gimme contributors"
6060
readonly GIMME_LICENSE_URL="https://raw.githubusercontent.com/urfave/gimme/${GIMME_VERSION}/LICENSE"
6161
export GIMME_VERSION

0 commit comments

Comments
 (0)