Skip to content

Commit c451a74

Browse files
da2ce7da2ce7
committed
docs: update release process
1 parent 6d3aa9d commit c451a74

File tree

1 file changed

+55
-48
lines changed

1 file changed

+55
-48
lines changed

‎docs/release_process.md‎

Lines changed: 55 additions & 48 deletions
Original file line numberDiff line numberDiff line change
@@ -1,68 +1,75 @@
1-
# Torrust Tracker Release Process (v2.1.0-draft)
1+
# Torrust Tracker Release Process (v2.2.0)
22

3-
The purpose of this document is to describe the release process.
3+
## Version:
4+
> **The `[semantic version]` is bumped according to releases, new features, and breaking changes.**
5+
>
6+
> *The `develop` branch uses the (semantic version) suffix `-develop`.*
47
5-
## Overview
8+
## Process:
69

7-
Torrust Tracker is published according to this protocol:
10+
### 1. The `develop` branch is ready for a release.
11+
The `develop` branch should have the version `[semantic version]-develop` that is ready to be released.
812

9-
0. After release create new pull request into `develop` branch:
13+
### 2. Stage `develop` HEAD for merging into the `main` branch:
1014

11-
- The `develop` branch has the (semantic version) suffix `-develop`.
12-
- The version is bumped according to releases, new features, and breaking changes.
15+
```sh
16+
git fetch --all
17+
git push --force torrust develop:staging/main
18+
```
1319

14-
- [ ] `develop` is ready for branching for a release.
15-
- [ ] force-push `develop` to `staging/main` branch.
16-
- [ ] commit `release: version (semantic version)`, that removes the `-develop` suffix.
17-
- [ ] create pull request to merge `staging/main` into `main` branch.
18-
- [ ] push `main` branch to `releases/v(semantic version)` branch.
19-
- [ ] check all status checks success for `releases/(semantic version)` branch.
20-
- [ ] create signed `v(semantic version)` tag from `releases/(semantic version) HEAD`.
21-
- [ ] create github release from `v(semantic version)` tag.
22-
- [ ] force-push `main` to `staging/develop` branch.
23-
- [ ] commit `develop: bump version (semantic version)-develop`, that bumps the version and adds the `-develop` suffix.
24-
- [ ] create pull request to merge `staging/develop` into `develop` branch.
20+
### 3. Create Release Commit:
2521

26-
- At step `1.`, `develop` is automatically published to `dockerhub`.
27-
- At step `3.`, `main` is automatically published to `dockerhub`.
28-
- At step `6.`, `releases/v(semantic version)` is automatically published to `dockerhub` and `crate.io`.
22+
```sh
23+
git stash
24+
git switch staging/main
25+
# change `[semantic version]-develop` to `[semantic version]`.
26+
git add -A
27+
git commit -m "release: version [semantic version]"
28+
git push torrust
29+
```
2930

30-
## Development Branch
31+
### 4. Create and Merge Pull Request from `staging/main` into `main` branch.
32+
This pull request merges the new version into the `main` branch.
3133

32-
The `develop` branch, the default branch for the repository is automatically published to dockerhub with the `develop` label. This process happens automatically when a pull request is merged in, and the `container.yaml` workflow is triggered.
34+
### 5. Push new version from `main` HEAD to `releases/v[semantic version]` branch:
3335

34-
## Main Branch
36+
```sh
37+
git fetch --all
38+
git push torrust main:releases/v[semantic version]
39+
```
3540

36-
The `main` branch is the staging branch for releases.
41+
> **Check that the deployment is successful!**
3742
38-
A release commit needs to be made that prepares the repository for the release, this commit should include:
43+
### 6. Create Release Tag:
3944

40-
- Changing the semantic version.
41-
- Finalizing the release notes and changelog.
45+
```sh
46+
git switch releases/v[semantic version]
47+
git tag --sign v[semantic version]
48+
git push --tags torrust
49+
```
4250

43-
The title of the commit should be: `release: version (semantic version)`.
51+
### 7. Create Release on Github from Tag.
52+
This is for those who wish to download the source code.
4453

45-
This commit should be committed upon the head of the development branch, and pushed to the `main` branch.
54+
### 8. Stage `main` HEAD for merging into the `develop` branch:
55+
Merge release back into the develop branch.
4656

47-
Once the release has succeeded, the `main` branch should be merged back into the `develop` branch.
57+
```sh
58+
git fetch --all
59+
git push --force torrust main:staging/develop
60+
```
61+
### 9. Create Comment that bumps next development version:
4862

49-
## Releases Branch
63+
```sh
64+
git stash
65+
git switch staging/main
66+
# change `[semantic version]` to `(next)[semantic version]-develop`.
67+
git add -A
68+
git commit -m "develop: bump to version (next)[semantic version]-develop"
69+
git push torrust
70+
```
5071

51-
According to the patten `releases/v(semantic version)`, the `main` branch head is published to here to trigger the deployment workflows.
72+
### 10. Create and Merge Pull Request from `staging/develop` into `develop` branch.
73+
This pull request merges the new release into the `develop` branch and bumps the version number.
5274

53-
The repository deployment environment for crates.io is only available for the `releases/**/*` patten of branches.
5475

55-
Once the publishing workflows have succeeded; we can make the git-tag.
56-
57-
## Release Tag
58-
59-
Create a Signed Tag with a short message in the form `v(semantic version)` and push it to the repository.
60-
61-
## Github Release
62-
63-
From the newly published tag, create a Github Release using the web-interface.
64-
65-
66-
## Merge back into development branch
67-
68-
After this is all successful, the `main` branch should be merged into the `develop` branch.

0 commit comments

Comments
 (0)