Skip to content

Commit 927c6df

Browse files
authored
Merge pull request #556 from input-output-hk/team/500/adr_release_process
ADR of the release process
2 parents 77687e6 + 8199c7a commit 927c6df

File tree

2 files changed

+76
-0
lines changed

2 files changed

+76
-0
lines changed
168 KB
Loading

docs/adr/003-release/index.md

Lines changed: 76 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,76 @@
1+
---
2+
slug: 3
3+
title: |
4+
3. Release process and versioning
5+
authors:
6+
- name: Mithril Team
7+
tags: [Draft]
8+
---
9+
10+
## Status
11+
12+
**draft**
13+
14+
## Context
15+
16+
In order to deliver regularly the software to our users, we should implement a release process based on a predictable versioning scheme.
17+
18+
### Versioning
19+
20+
A Release Version determines a distribution of determined node versions and underlying libraries.
21+
22+
* Our softwares must be able to interact seamlessly with other Mithril software.
23+
* Our softwares must be able to be hosted on crates.io.
24+
* Our softwares must clearly indicate compatibility with other Mithril components to end users.
25+
26+
27+
### Release process
28+
29+
A Release is a software package that is built once and then promoted from the testing environment to the production environment. It can be signed.
30+
31+
* Keep it simple.
32+
* Automated as much as possible: all points not requiring human decision shall be automated.
33+
* Minimize the mean time to release.
34+
35+
## Decision
36+
37+
There are 3 versioned layers in the Mithril stack:
38+
39+
* HTTP API protocol to ensure compatibility in the communication between nodes (use Semver).
40+
* Crate version: each node & library has its own version (use Semver). The commit digest is automatically added to the version by the CI pipeline.
41+
* Release Version: the distribution version (use version scheme **YYWW.patch** | **YYWW.patch-name**). The VERSION file is computed by the pipeline from the tag release.
42+
43+
The documentation is tied to a Release Version.
44+
45+
### Release Process
46+
47+
Starting just after a new release has been made:
48+
49+
1. Develop on a dedicated development branch.
50+
1. When merging PR on main: update the `Cargo.toml` files with version of the updated nodes.
51+
1. Once merged, the CI creates an `unstable` tag & release which is deployed on testing environment.
52+
1. Push a tag using the distribution version format on this commit with a `-prerelease` suffix.
53+
1. The CI gets the built artifacts associated with this commit and generates a named pre-release which is deployed on `pre-release` for testing.
54+
1. Push a tag using the distribution version format on this commit without the `-prerelease` suffix.
55+
1. The CI gets the built artifacts associated with this commit and generates a named release which is deployed on `pre-release` for testing.
56+
1. In the release GitHub interface, edit the newly generated release, uncheck the `This is a pre-release` checkbox.
57+
1. The CI gets the built artifacts associated with this commit and generates a named release which is deployed on `release`.
58+
1. Create a commit:
59+
1. to promote the documentation website from future to current.
60+
1. to update the SQL schema with alterations from the previous release.
61+
62+
[![Release Process](./img/release_process.jpg)](./img/release_process.jpg)
63+
64+
### Hotfix Release
65+
66+
In case of a blocking issue (following a distribution release) on the release environment that requires an immediate fix:
67+
68+
1. Create a branch on the last release tag with the following scheme: **hotfix/{last_distribution-version}.{last_patch_number + 1}**.
69+
1. Development of the fix is done on this branch.
70+
1. After each commit on this branch, the CI creates an `unstable` tag & release which is not deployed on testing environment (testing must be done on an ad hoc environment manually created).
71+
1. Push a tag on the branch last commit using the branch distribution version with a `-hotfix` suffix.
72+
1. The CI gets the built artifacts associated with this commit and generates a named pre-release which is deployed on `pre-release` for testing.
73+
1. In the release GitHub interface, edit the newly generated release, uncheck the `This is a pre-release` checkbox.
74+
1. The CI gets the built artifacts associated with this commit and generates a named release which is deployed on `release`.
75+
1. Merge the hotfix branch on main branch (and adapt the changes if they are not compatible with the current main branch).
76+

0 commit comments

Comments
 (0)