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 freezing our release candidate:
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.
Check for any upstream storage migrations and perform tests with try-runtime, if any.
Update hard-coded URLs to polkadot/manta binaries/runtimes in publish_draft_releases.yml CI workflow.
The following checks can be performed after we have frozen our release candidate:
Code freeze should typically happen one week prior to release, to ensure we have enough time for related testing.
Notify everyone, especially people with merge rights to manta (stechu, Dengjianping) that a release is ongoing and no more merges to manta should happen until told otherwise
Check that build artifacts have been added to the
draft-release
Coordinate with marketing team for documentation updates and other relevant tasks.
Update changelog.
If the release contains any changes that break/change functionality used in https://github.com/Manta-Network/sdk (e.g. RPC changes, see also extrinsic ordering), raise a PR there and block this release until your PR has been merged and incorporated in a new SDK release.
Check that the new client and/or runtime versions have burned-in without issue for at least 3 days.
Before declaring a successful burn-in make sure to check for anomalies in our nodes' memory, cpu, disk and network usage via the Grafana Node Explorer. These would include but are not limited to: memory leaks, cpu spikes, spike in tcp sockets waiting to close, etc. Make sure to take a look at all of the available graphs, because some problems might only show up in the collapsed views.
Note: Do not publish draft releases from PR branches, because those branches will be deleted when the PR is merged.
Notes
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. To generate a diff report you can do the following:
Lean checklist due to pre-release
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 freezing our release candidate:
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.
try-runtime
, if any.Update hard-coded URLs to polkadot/manta binaries/runtimes inpublish_draft_releases.yml
CI workflow.The following checks can be performed after we have frozen our release candidate:
Code freeze should typically happen one week prior to release, to ensure we have enough time for related testing.Notify everyone, especially people with merge rights tomanta
(stechu, Dengjianping) that a release is ongoing and no more merges tomanta
should happen until told otherwiseruntime changes.
Execute runtime upgrade to Baikal relay and verify network stability.Execute runtime upgrade to Calamari @ Baikal and verify network stability.Execute runtime upgrade to Calamari @ Moonbase-Relay and verify network stability.Execute runtime upgrade to Dolphin @ Baikal and verify network stability.Note: Usually update client first then runtime.
Client Releases
version
has been bumped from previous release.Update client of Baikal relay nodes.Update client of Calamari-Testnet @ Baikal nodes.Update client of Calamari-Testnet @ Moonbase-Relay nodes.Update client of Dolphin @ Baikal nodes.All Releases
https://github.com/Manta-Network/Manta/releases with relevant release
notes
draft-release
Coordinate with marketing team for documentation updates and other relevant tasks.Update changelog.If the release contains any changes that break/change functionality used in https://github.com/Manta-Network/sdk (e.g. RPC changes, see also extrinsic ordering), raise a PR there and block this release until your PR has been merged and incorporated in a new SDK release.Check that the new client and/or runtime versions have burned-in without issue for at least 3 days.Before declaring a successful burn-in make sure to check for anomalies in our nodes' memory, cpu, disk and network usage via the Grafana Node Explorer. These would include but are not limited to: memory leaks, cpu spikes, spike in tcp sockets waiting to close, etc. Make sure to take a look at all of the available graphs, because some problems might only show up in the collapsed views.Note: Do not publish draft releases from PR branches, because those branches will be deleted when the PR is merged.
Notes
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. To generate a diff report you can do the following:Run workflow
drop-down menu.output.txt
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)
In case of a breaking change, bump the
transaction_version
.Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The text was updated successfully, but these errors were encountered: