Skip to content

Draft 2 of Release Process Document #432

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 15, 2023
Merged

Draft 2 of Release Process Document #432

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 18 additions & 12 deletions docs/release_process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,24 +1,30 @@
# Torrust Tracker Release Process (draft)
# Torrust Tracker Release Process (draft 2)

The purpose of this document is to describe the release process.

## Overview

Torrust Tracker is published in this order:
Torrust Tracker is published according to this protocol:

1. `develop` branch is ready for publishing.
2. create `release: version (semantic version)` commit.
3. push release commit to `main` branch.
4. check all status checks succeed for `main` branch.
5. push `main` branch to `releases\v(semantic version)` branch.
6. check all status checks success for `releases\v(semantic version)` branch.
7. create signed `v(semantic version)` tag.
8. create github release from `v(semantic version)` tag.
9. merge `main` branch into `develop` branch.
0. After release create new pull request into `develop` branch:

- The `develop` branch has the (semantic version) suffix `-develop`.
- The version is bumped according to releases, new features, and breaking changes.

- [ ] `develop` is ready for branching for a release.
- [ ] force-push develop to `staging` branch.
- [ ] commit `release: version (semantic version)`, removing the `-develop` suffix.
- [ ] create pull request to merge `staging` into `main` branch.
- [ ] check all status checks succeed for `main` branch.
- [ ] push `main` branch to `releases\v(semantic version)` branch.
- [ ] check all status checks success for `releases\v(semantic version)` branch.
- [ ] create signed `v(semantic version)` tag from `releases\v(semantic version) HEAD`.
- [ ] create github release from `v(semantic version)` tag.
- [ ] merge the `main` branch back into `develop` branch, assuring that the (semantic version) has the suffix `-develop`.

- At step `1.`, `develop` is automatically published to `dockerhub`.
- At step `3.`, `main` is automatically published to `dockerhub`.
- At step `5.`, `releases\v(semantic version)` is automatically published to `dockerhub` and `crate.io`.
- At step `6.`, `releases\v(semantic version)` is automatically published to `dockerhub` and `crate.io`.

## Development Branch

Expand Down