Cumulus v0.9.230 Release checklist

[github-actions]

Release Checklist

( for v9230 cgp runtime release see #1366 )

Runtime Releases

These checks should be performed on the codebase.

• Verify spec_version has been incremented since the
  last release for any native runtimes from any existing use on public
  (non-private/test) networks.

The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)

• Push runtime upgrade to Westmint and verify network stability and check that any new migrations have been run successfully.

All Releases

• Check that the new polkadot-parachain versions have run on the network
  without issue.
• Check that a draft release has been created at
  https://github.com/paritytech/cumulus/releases with relevant release
  notes.
• Check that build artifacts have been added to the
  draft-release.

---

Notes

Burn In

Ensure that Parity DevOps has run the new release on Westmint and Statemine collators for 12h prior to publishing the release.

Build Artifacts

Add any necessary assets to the release. They should include:

• Linux binary
• GPG signature of the Linux binary
• SHA256 of binary
• Source code

Release notes

The release notes should list:

• The priority of the release (i.e., how quickly users should upgrade) - this is
  based on the max priority of any client changes.
• Which native runtimes and their versions are included
• Any changes in this release that are still awaiting audit

The release notes may also list:

• Free text at the beginning of the notes mentioning anything important
  regarding this release
• Notable changes separated into sections.

Spec Version

A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).

Runtime version bump between RCs

The clients need to be aware of runtime changes. However, we do not want to bump the
spec_version for every single release candidate. Instead, we can bump the impl field of the version
to signal the change to the client.

[gilescope]

(Have updated this to remove references to runtimes as these are covered in a separate release.)

[chevdor]

The issue discovered in the previous burnin has been fixed and a new burnin is requested.