Release Cycle

Spacemesh Release Cycle

The release cycle takes a new nodes and deploys a network for it. While the node is the main program the smeshnet is more than just a node. There are a number of components that all need to work together for a smeshnet to work, including poet, smapp, the testnet tap, explorer backend, explorer frontend, dashboard, monitoring, go-spacecraft, and CLIWallet.

Review & Name

When it's time to release a version, the release manager kicks off by reviewing the git log, comparing to the changelog, polishing it and naming the version. We follow SemVer so to choose and a nam, the managers starts with the last name and:

• If it breaks compatbility, increment the major
• If it adds a new feture, increment the minor
• If it fixes node bugs, increment the patch

Assuming the chosen name is "1.2.3", the release manager will updated the changelog, replacing Unreleased with 1.2.3 and enter the date. The he comitts this and all under edits under "Releasing v1.2.3".

Build

Once the manager is finished he tags the version with the name + a build number. In the first build the version is named v1.2.3+1. Then the manager git push --tags to start the deployments.

Deploy

SemVer tags with a build number trigger a CI process that uses go-spacecraft to deploy a new network. The pipeline will first update the devnext branch and then bootstrap the network.

Smoke Test

Once the network is up, the CI Process will run a small suite of tests to ensure deployment was a success.

Post-Deployment

After the smoke test there are a few extra steps that run:

• deploying the explorer and dashboard
• deploying the discovery service
• deploying public gRPC service and ensure it's alive
• pointing dns records of 1_2_3_1.net.spacemesh.io at the new network
• releasing SMApp
• generating & publishing a static html page with all the version-related information
• updating the devnet branch to point at the version

Simmer

Let the network run for at least 7 days while visiting the dashboard daily. If consensus totally fails (i.e., the verified layer totally stops advancing), or another serious issue occurs, then it's obviously time to retire that network.

Release

Once the manager is satisified with the network's quality he releases it by tagging it with a version like "v1.2.3".

Integrate

SemVer tags with no build number will trigger a pipeline to:

• pointing testnet DNS records at the new network
• generating & publishing an info page at test.net.spacemesh.io
• updating the testnet branch to point to the latest tag

Announce

Manually update the install links in the sire and announce the new version on discord, twitter, etc..

Retire the old testnet

Make sure that the prior testnet is completely retired at this stage. All managed nodes should be shut down and logs should be archived for future reference.

Handling Failures

In case of failures of deployment, investigate, fix and release under an incremented build number as in v1.2.3+2.

In case of smeshnet failures Write a postmortem, or a recap (if it died a natural death), and publish it in the Spacemesh blog. Describe any issues that arose, how we responded to them, and the plan for the next smeshnet.