Skip to content

Commit df6d72d

Browse files
committed
Merge branch 'refs/heads/main' into develop
2 parents 59aafab + 85d02b3 commit df6d72d

File tree

1 file changed

+71
-0
lines changed

1 file changed

+71
-0
lines changed

RELEASE.md

+71
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
# Release
2+
3+
This document explains the current release procedure for the Glide project.
4+
5+
A person that handles the release is called the release manager.
6+
7+
The release version should be picked based on the previous version and changes that are going to be released:
8+
- If the previous version was `0.0.3` and changeset doesn't have breaking changes in API, the next version may be either `0.0.4-rc.1`.
9+
- If the previous version was `0.0.3-rc.2` and changeset doesn't have breaking changes in API, the next version may be either `0.0.3-rc.3` or `0.0.3`.
10+
- if the previous version was `0.0.3` and changeset has breaking changes in API, the next version may be either `0.1.0-rc.1` or `0.1.0`.
11+
12+
It's encouraged to have a release candidate as an intermediate step in the releasing the "stable" version.
13+
14+
## The release process
15+
16+
The following is step-by-step instruction.
17+
18+
### The release PR
19+
20+
The release manager creates a new pull request from the `develop` branch into the `main`.
21+
22+
### Collect changelog
23+
24+
The changeset from the PR should be reviewed and represented as a changelog in the `CHANGELOG.md` file.
25+
26+
Git can be helpful to summarize changes:
27+
28+
```bash
29+
git log --pretty=format:"%s (%an)" {LAST_VERSION_TAG}..HEAD
30+
```
31+
32+
Sort out all changes to the categories they belong to.
33+
34+
### Update the release PR description
35+
36+
Use the created changelog to update the PR description.
37+
38+
### Merge the release PR
39+
40+
Once all checks are green on the Release PR, you can merge it into the main.
41+
When squashing the pull request, please specify the same changelog you have added to the PR description.
42+
43+
### Tag the merge commit
44+
45+
Tag the merge commit in the main branch using the release version like `0.1.0-rc.1`.
46+
47+
That should trigger a deployment pipeline that can be checked under https://github.com/EinStack/glide/actions.
48+
49+
Wait until the pipeline is done or failed.
50+
51+
### Create a GitHub release
52+
53+
The release manager then creates a release in GitHub for the released version.
54+
The GitHub release should contain the same changelog message we have used in the release PR description.
55+
56+
The release should be marked as a pre-release if the version is a release candidate or a stable release otherwise.
57+
58+
Feel free to announce the release via creating a discussion (there is a checkbox for that on the new GitHub release form).
59+
60+
### Spread a word about the release
61+
62+
The release manager should spread a word about the release in the Discord community space.
63+
64+
Please use the `#announcements` channel for announcing stable releases.
65+
You can use `#general` to announce release candidates.
66+
67+
Be sure to do shutouts for people who spend their time improving the project.
68+
69+
| Releases | Release Manager |
70+
|------------------|-----------------|
71+
| 0.0.1-0.1.0-rc.1 | @roma-glushko |

0 commit comments

Comments
 (0)