What to release
- Archives with platform-specific executables for Linux and Mac
- Bundling the version of circuits guaranteed to work with the released binary
- We add a README in the bundle with instructions on how to link those circuits to the node binary (e.g., point to the directory that contains them before running the binary)
- Checksums for all binaries and how to verify them
- Changelogs
- For each major release, changes from the last release of the previous major
- For each minor release, changes from the last release of the previous minor
- For each patch release, changes from the previous patch release of the same minor
Open Points
- Where do we push our Docker images?
Future additions
How to release
- Semantic versioning
- Each time circuits change → hard forks → new major
- New non-consensus-breaking features → potential soft forks → new minor
- Bug-fixing → new patch
- We will start with
0.1.0 as the first version we will deploy on the very first testnet
- We will use
1.0.0 for our first mainnet version
- Release-specific CI jobs must be ✅ before triggering a release workflow with the final bundles
- We will set up workflows specifically for creating GH releases, publish artifacts, automatically deploy on a target network, following the testing → staging → production lifecycle
- All PRs merged on
master
- Branch-off at a set point, apply rc tags, test, apply patches on
master and release-specific patches to the release branch, tag, repeat.
- Such changes include updating the crate version of all workspace members to be the same one. This is already the case as all members inherit the workspace version.
- We backport the updates to the past N releases, generating a new GH release for each of them (maybe not in the beginning tho, as that could be time consuming).
- We follow the same release process for each of those new releases, going from rc to a new GH release for each of the releases affected
- Each new release candidate starts with an
rc tag, e.g., 0.1.0-rc.1. No GH release yet.
- Rc candidates are deployed on internal networks first.
- We need to define a checklist of things to do/check when testing on internal network.
- Applying patches would result in a new candidate, e.g.,
0.1.0-rc.2.
- Once stable enough, they are promoted to public release candidates. We should point at the same commit as the tip of the rc that was tested.
- We would create a new GH release and mark it as pre-release
- This is what gets deployed on public testnet(s)
- We need to define a checklist of things to do/check when testing on internal network.
- Once stable enough, we make a new official tag, e.g.,
0.1.0 that should point at the same commit as the last release candidate, and we create a new GH release for it
- At least one more person must review the release draft before pushing the button.
- We can start with doing this by hand, and then look at strategies to automate this, if needed
- This is what gets deployed on mainnet
Open Points
- What tests can we run on a live network?
- Should we spin up a new network made of nodes running the to-be-released version for testing?