|
| 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 | +[](./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