You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of the following checks should be completed before officially publishing the new release
of the Calamari/Manta runtime or client. Some need to be completed after the new code is deployed.
Runtime Releases
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
Verify spec_version has been incremented since the
last release for any native runtimes from any existing use on public
(non-private/test) networks. If the runtime was published (release or pre-release), either
the spec_version or impl must be bumped.
Verify pallet and extrinsic ordering has stayed
the same. Bump transaction_version if not.
Verify new extrinsics have been correctly whitelisted/blacklisted
Verify benchmarks have been updated for any modified
runtime logic.
The following checks can be performed after we have forked off to the release branch.
Ensure that Manta DevOps has run the new release on Como and Baikal nodes
for at least 12 hours prior to publishing the release.
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
The proposal hashes of the runtimes as built with srtool
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 (those labelled with B[1-9]-* labels) separated into sections
Spec Version
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release
Extrinsic Ordering
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index tuples map to the same set of functions. In case
of a breaking change, increase transaction_version.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15) - indicates the index for Identity has changed
[+] Society, Recovery - indicates the new version includes 2 additional modules/pallets.
If no indices have changed, every modules line should look something like [Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
Benchmarks
There are three benchmarking machines reserved for updating the weights at
release-time. To initialise a benchmark run for each production runtime
(calamari, manta):
Release Checklist
Most of the following checks should be completed before officially publishing the new release
of the Calamari/Manta runtime or client. Some need to be completed after the new code is deployed.
Runtime Releases
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thelast release for any native runtimes from any existing use on public
(non-private/test) networks. If the runtime was published (release or pre-release), either
the
spec_version
orimpl
must be bumped.the same. Bump
transaction_version
if not.runtime logic.
The following checks can be performed after we have forked off to the release branch.
runtime changes.
All Releases
without issue for 12 hours.
https://github.com/Manta-Network/Manta/releases with relevant release
notes
draft-release
After Runtime Upgrade
Notes
Burn In
Ensure that Manta DevOps has run the new release on Como and Baikal nodes
for at least 12 hours prior to publishing the release.
Release notes
The release notes should list:
based on the max priority of any client changes.
srtool
The release notes may also list:
regarding this release
Spec Version
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release
Extrinsic Ordering
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the
module index, call index
tuples map to the same set of functions. In caseof a breaking change, increase
transaction_version
.The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index forIdentity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
Benchmarks
There are three benchmarking machines reserved for updating the weights at
release-time. To initialise a benchmark run for each production runtime
(calamari, manta):
and Manta Benchmarking Github Action
be available to download as artifacts.
big outliers (i.e., twice or half the weight).
The text was updated successfully, but these errors were encountered: