Implement Release process

[jpraynaud]

Issue

We need to work on the release process in order to manage correctly the evolution of the network with our users

Here is a first definition of the Release Process for the Mithril Network:

• We will use a common version (semver) for all the crates of the repository and for the GitHub release
• All the nodes should be able to display the current version they are running
• In case of a version mismatch, the Aggregator should return an error so that the Signer/Client nodes are updated regularly
• We will work with GitHub environments to support deployments of versions on multiple environments
• A new version 0.1.2 will have the following life cycle:
  • A commit abc123 merged on main branch is deployed on testing environment named testing-preview
  • A commit def456 tagged with 0.1.2-prerelease1 is deployed on preprod environment named pre-release-preview
  • A GitHub release 0.1.2 is created and linked with the 0.1.2-prerelease1 tag and marked as pre-release
  • A tag 0.1.2-prerelease1 is qualified and selected for release or rejected (and replaced by a 0.1.2-prerelease2 tag if necessary on a ghj789 commit)
  • If the tag 0.1.2-prerelease1 is selected, a new tag is created and name 0.1.2 on the same commit def456
  • The GitHub release is linked to the 0.1.2 tag and marked as release
  • The commit def456 with tag 0.1.2 is deployed to the prod environment named release-preprod

Questions

• [x] When to update cargo.toml crates version vs creation of the draft release on GitHub?
• [x] How to handle merge lock during qualification of a release candidate (with only main branch) (Use of feature flag?)?
• [ ] How to handle Network Protocol Versions smoothly (backward compatibility of messages w/ Avro or Protocol Buffer or equivalent solution?)
• [x] How to simplify the update process for the SPOs (with debian package for example)?
• [ ] How to handle real SPOs on the testing-preview and pre-release-preprod environments (vs key rotations, secret keys management, ...)?

Main Tasks

• [x] #541
• [ ] #543
• [ ] #542
• [ ] #555
• [ ] #563

Other Tasks

• [ ] Define template for release notes
• [ ] Add a page on the documentation website that explains the release process
• [ ] Update documentation (https://mithril.network/doc/manual/developer-docs/references#mithril-networks)
• [ ] Update the SPO guide with a section explaining how to install of pre-compiled binaries of a release
• [x] Add backup of databases of all environments
• [x] Add backup SPO keys
• [ ] Add monitoring for nodes and/or status page on documentation website
• [ ] Add a Debian package in the artifacts produced by the CI
• [x] Add a multi target build (Linux, macOS, Windows) for the Client at least
• [ ] Add signature of binaries in the artifacts released (with GPG signature of the md5 of the binaries for example)
• [ ] Activate deployment to crates.io (including missing fields in cargo.toml)

Maybe Later / To be discussed Tasks

• [ ] Show version in Mithril Explorer

[abailly-iohk]

Perhaps a first step would be to define a release process along the lines of what we did together this afternoon and then talk with the small SPO community we have started to gather to get their feedback? I guess the testing/pre-releases will need to receive more or less attention from the SPOs so understanding how much time/effort they are ready to devote to this would help us calibrate the frequency and scope of releases?