Release management


The purpose of this page is to outline the work related to releasing new versions of RNode.

Process description

We release software at the end of each sprint, meaning we release whatever is in the dev branch at the end of the sprint.

At the end of a sprint

Tag a release based on whatever is in the dev branch

Example of a Jira ticket  RCHAIN-3597 - Getting issue details... STATUS

Note: Ideally we should run this release in devnet for 24 hours to look at stability. In some cases, we've run dev in devnet before tagging the release. In other cases, we need to get a fix to the public testnet and just go ahead and upgrade.

SRE teamPM

Update the public testnet

Example of a Jira ticket  RCHAIN-3596 - Getting issue details... STATUS

SRE teamPM

Update the release page

  • Update page header information
  • Confirm work shown as included in the release is correct
  • Write plain English description of the highlights of the release under the heading "Release Summary"
    • What makes this release good?
    • Call out breaking changes
    • Call out changes impacting node operators and/or dapp developers

Example of a release page RNode-0.9.10 release plan


Create the next release in Jira.


Create release plan for the next release. Hint: copy the current release plan and edit

  • Header
  • Summary
  • Jira macros

Update The Flight to Mercury

  • Update listing for current release
  • Create new listing for next release
When all items above complete

Create a ticket for updating page and assign to Derek Beres

Example of a Jira ticket  WEB-160 - Getting issue details... STATUS . Note this is in the Web project in Jira and not RChain project.


Update developer.rchain.coopDerek BeresPM