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

• Add Docker images to the releases, along with expected checksums
• Sign releases, e.g., https://wiki.debian.org/Creating signed GitHub releases

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?