Polkadot v0.9.10 Release checklist

[github-actions]

Release Checklist

This is the release checklist for Polkadot v0.9.10. All following
checks should be completed before publishing a new release of the
Polkadot/Kusama/Westend runtime or client. The current release candidate can be
checked out with git checkout release-v0.9.10

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.
• Verify previously completed migrations are
  removed for any public (non-private/test) networks.
• Verify pallet and extrinsic ordering has stayed
  the same. Bump transaction_version if not.
• Verify new extrinsics have been correctly whitelisted/blacklisted for
  proxy filters.
• Verify benchmarks have been updated for any modified
  runtime logic.

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)

• Verify new migrations complete successfully, and the
  runtime state is correctly updated for any public (non-private/test)
  networks.
• Verify Polkadot JS API are up to date with the latest
  runtime changes.
• Push runtime upgrade to Westend and verify network stability.

All Releases

• Check that the new client versions have run on the network
  without issue for 12 hours.
• Check that a draft release has been created at
  https://github.com/paritytech/polkadot/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 Westend, Kusama, and
Polkadot validators for at least 12 hours 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
• Wasm binaries of any runtimes

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 (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).

Old Migrations Removed

Any previous on_runtime_upgrade functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade function
can be found in runtime/<runtime>/src/lib.rs.

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 case
of a breaking change, increase transaction_version.

To verify the order has not changed:

1. Download the latest release-candidate binary either from the draft-release
   on Github, or
   AWS
   (adjust the rc in this URL as necessary).
2. Run the release-candidate binary using a local chain:
   ./polkadot --chain=polkadot-local or ./polkadot --chain=kusama.local
3. Use polkadot-js-tools to compare
   the metadata:

• For Polkadot: docker run --network host jacogr/polkadot-js-tools metadata wss://rpc.polkadot.io ws://localhost:9944
• For Kusama: docker run --network host jacogr/polkadot-js-tools metadata wss://kusama-rpc.polkadot.io ws://localhost:9944

4. 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 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):

• Go to https://gitlab.parity.io/parity/polkadot/-/pipelines?page=1&scope=branches&ref=master
• Click the link to the last pipeline run for master
• Start each of the manual jobs:
  • 'update_westend_weights'
  • 'update_polkadot_weights'
  • 'update_kusama_weights'
• When these jobs have completed (it takes a few hours), a git PATCH file will
  be available to download as an artifact.
• On your local machine, branch off master
• Download the patch file and apply it to your branch with git patch patchfile.patch
• Commit the changes to your branch and submit a PR against master
• The weights should be (Currently manually) checked to make sure there are no
  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.

[stringa]

I would love to see a full sync of parachain as part of the acceptance criteria. I have another thread open about how I've not been able to achieve a full sync using multiple different versions of Polkadot and Ubuntu. Maybe I'm doing something wrong, but it doesn't break until you are well over a 50% sync

paritytech/polkadot-sdk#951

[s3krit]

No runtime migrations this time - checking box. Though I'm a little uncertain as to whether there should be or not. There are quite a few changes, especially around the XCM stuff. Does none of this require a storage migration? @rphmeier @shawntabrizi maybe you could shed some light? List of changes can be found here : #3763

[s3krit]

Transaction version will be bumped as part of #3865 . Attached are the metadata changes, though the bump is also due to #3693

kusama-metadata.txt
polkadot-metadata.txt
westend-metadata.txt

[s3krit]

@shawntabrizi are you able to confirm the correct proxy whitelists have been added for the additional calls linked in the previous comment's attachments?

[shawntabrizi]

No runtime migrations this time

Are you sure?

There are like 4 outstanding migrations in master: https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/lib.rs#L1145

None of them made it into this PR? (i.e. the substrate version being used does not have these needed changes?)

[s3krit]

Yeah, this release was based off v0.9.9-1, only including what changes were required for XCMv1 - initially it was supposed to be quite a short list but it somewhat ballooned. The changes @chevdor listed in his PR here detail the changes. If those cherry-picked PRs just didn't include any migrations, it is probably fine, I just thought it prudent to double-check. I'll go over those PRs myself

[shawntabrizi]

There is def a runtime upgrade here: https://github.com/paritytech/polkadot/pull/3575/files

still looking through other changes

[chevdor]

I had a chat with @jacogr. Runtime 9100 is a V13. The suggested PolkadotJS API is 6.0.5+ and supports already V14 as well.

[jacogr]

The previous 5.9.2 is fine as well. So would not force an API upgrade (it is obviously appreciated if people bump, but not required)

[chevdor]

Regarding the proxy verification, I see from the metadata the following call additions:

Kusama & Westend

• Configuration.setUmpMaxIndividuaWeight
• Ump.serviceOverweight
• Hrmp.hrmpCancelOpenRequest

Polkadot

n/a

I do not think those need to be added to any Proxy. @pepyakin can you confirm ?

[chevdor]

I had a chat with @pepyakin and the conclusion is that non of the mentioned extrinsics do direct transfers. They also don't fit other ProxyType but ProxyType::Any.

[chevdor]

Migrations

We have 2 migrations left:

• here @HCastano
• here coming from here (@pepyakin )

[lovelaced]

Runtime upgrade to Westend applied.