This repository was archived by the owner on Nov 15, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 379
Statemine v4 Release Checklist #627
Labels
T7-system_parachains
This PR/Issue is related to System Parachains.
Comments
release candidate: #626 |
Introduced in #572, merged on the 13.8. |
need to bump transaction version because of paritytech/polkadot#3693 |
I 👍 the above from another angle: statemine
westmint
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Release Checklist
This is the release checklist for Statemine v4. All following
checks should be completed before publishing a new release of the
Statemine runtime. The current release candidate can be
checked out with
git checkout release-statemine-v4
Runtime Releases
These checks should be performed on the codebase.
spec_version
has been incremented since thelast release for any native runtimes from any existing use on public
(non-private/test) networks.
removed for any public (non-private/test) networks. => See comment
the same. Bump
transaction_version
if not. @chevdortransaction_version
proxy filters.
runtime logic. @NachoPal
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)
runtime state is correctly updated for any public (non-private/test)
networks. (There should be no migrations for this release.)
runtime changes.
All Releases
without issue.
https://github.com/paritytech/cumulus/releases with relevant release
notes
draft-release
Notes
Burn In
Ensure that Parity DevOps has run the new release on Westmint and Statemine collators prior to publishing the release.
Build Artifacts
Add any necessary assets to the release. They should include:
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 (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Old Migrations Removed
Previous
on_runtime_upgrade
functions from old upgrades should be removed.New Migrations
Ensure that any migrations that are required due to storage or logic changes
are included in the
on_runtime_upgrade
function of the appropriate pallets.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
.To verify the order has not changed:
on Github.
polkadot-js-tools
to comparethe metadata:
[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 they are added to the end of a pallet (i.e., does not break any
other call index).
Proxy Filtering
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Benchmarks
There are three benchmarking machines reserved for updating the weights at
release-time. To initialise a benchmark run for each production runtime
(westend, kusama, polkadot):
be available to download as an artifact.
git patch patchfile.patch
big outliers (i.e., twice or half the weight).
Polkadot JS
Ensure that a release of Polkadot JS API contains any new types or
interfaces necessary to interact with the new runtime.
The text was updated successfully, but these errors were encountered: