Checklist For {{ Env.VERSION }} Release

by ADMIN 40 views

As we prepare for the release of Zeitgeist {{ env.VERSION }}, it's essential to ensure that all necessary checks are completed to guarantee a smooth and successful deployment. This comprehensive checklist outlines the critical steps to take before publishing a new release of the Zeitgeist runtime or client.

Runtime Releases

Before forking to a release-candidate branch, it's crucial to verify the following:

Verify Spec Version Incrementation

  • Verify that the spec_version has been incremented since the last release for any native runtimes from any existing use on public (non-private/test) networks.
  • This ensures that the new release is compatible with the existing infrastructure and prevents potential conflicts.

Verify Removed Migrations

  • Verify that previously completed migrations are removed for any public (non-private/test) networks.
  • This step is essential to prevent duplicate migrations and maintain the integrity of the runtime.

Verify Pallet and Extrinsic Ordering

  • Verify that pallet and extrinsic ordering has stayed the same. Bump transaction_version if not.
  • This ensures that the ordering of pallets and extrinsics remains consistent, which is critical for offline signing libraries and other dependent components.

Verify New Extrinsic Whitelisting/Blacklisting

  • Verify that new extrinsics have been correctly whitelisted/blacklisted for proxy filters.
  • This step ensures that the new release is compatible with the existing proxy filters and prevents potential security vulnerabilities.

Verify Updated Benchmarks

  • Verify that benchmarks have been updated for any modified runtime logic.
  • This step ensures that the new release is optimized for performance and provides accurate benchmarking results.

Release Candidate Branch Checks

After forking to the release-candidate branch or starting an additional release candidate branch (rc-2, rc-3, etc), perform the following checks:

Verify New Migrations Completion

  • Verify that the new migrations complete successfully, and the runtime state is correctly updated for any public (non-private/test) networks.
  • This step ensures that the new release is compatible with the existing infrastructure and prevents potential conflicts.

Verify SDK Updates

  • Verify that the SDK is up-to-date with the latest changes.
  • This step ensures that developers have access to the latest features and bug fixes.

Run Integration Tests and Upgrade Tests

  • Run integration tests and check if upgrade tests executed successfully.
  • This step ensures that the new release is compatible with the existing infrastructure and prevents potential conflicts.

Push Runtime Upgrade to Battery Station and Mainnet

  • Push runtime upgrade to Battery Station and ensure network stability for 24 hours.
  • Push runtime upgrade to Zeitgeist mainnet.
  • This step ensures that the new release is deployed to the production environment and is stable.

All Releases

Perform the following checks for all releases:

Verify Client Version Compatibility

  • Check that the new client versions have run on the network without issue for 12 hours.
  • This step ensures that the new release is compatible with the existing infrastructure and prevents potential conflicts.

Create Draft Release

  • Check that a draft release has been created at https://github.com/zeitgeistpm/zeitgeist/releases with relevant release notes.
  • This step ensures that the new release is properly documented and provides valuable information to developers and users.

Add Build Artifacts

  • Check that build artifacts have been added to the draft-release.
  • This step ensures that developers have access to the necessary assets for development and testing.

Notes

Build Artifacts

Add any necessary assets to the release, including:

  • Linux binary
  • GPG signature of the Linux binary
  • SHA256 of the Linux binary
  • Source code
  • Wasm binaries of the runtime

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.
  • The version of the native runtime
  • The proposal hashes of the runtime 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 separated into sections

Spec Version

A runtime upgrade must bump the spec version 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 the old upgrades must be removed to prevent them from executing a second time.

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. Build the Zeitgeist client from source: git clone https://github.com/zeitgeistpm/zeitgeist.git zeitgeist-release && pushd zeitgeist-release > /dev/null && cargo build --features=parachain

  2. Run the release-candidate binary using a local chain: ./target/debug/zeitgeist --chain=battery_station --tmp

  3. Use polkadot-js-tools to compare the metadata: docker run --network host jacogr/polkadot-js-tools metadata wss://bsr.zeitgeist.pm 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

Run the benchmarking suite with the new runtime and update any function weights if necessary.

Based on Parity's release checklist for Polkadot

As we prepare for the release of Zeitgeist {{ env.VERSION }}, we understand that you may have questions about the checklist and the process. Below, we've compiled a list of frequently asked questions to help clarify any doubts.

Q: What is the purpose of the release checklist?

A: The release checklist is a comprehensive guide to ensure that all necessary checks are completed before publishing a new release of the Zeitgeist runtime or client. This checklist helps prevent potential conflicts, ensures compatibility with existing infrastructure, and guarantees a smooth and successful deployment.

Q: Why is it essential to verify the spec version incrementation?

A: Verifying the spec version incrementation ensures that the new release is compatible with the existing infrastructure and prevents potential conflicts. This step is crucial to maintain the integrity of the runtime and prevent duplicate migrations.

Q: What is the significance of verifying removed migrations?

A: Verifying removed migrations ensures that previously completed migrations are removed for any public (non-private/test) networks. This step prevents duplicate migrations and maintains the integrity of the runtime.

Q: Why is it necessary to verify new extrinsic whitelisting/blacklisting?

A: Verifying new extrinsic whitelisting/blacklisting ensures that new extrinsics have been correctly whitelisted/blacklisted for proxy filters. This step prevents potential security vulnerabilities and ensures that the new release is compatible with the existing proxy filters.

Q: What is the purpose of verifying updated benchmarks?

A: Verifying updated benchmarks ensures that benchmarks have been updated for any modified runtime logic. This step ensures that the new release is optimized for performance and provides accurate benchmarking results.

Q: Why is it essential to run integration tests and upgrade tests?

A: Running integration tests and upgrade tests ensures that the new release is compatible with the existing infrastructure and prevents potential conflicts. This step guarantees a smooth and successful deployment.

Q: What is the significance of pushing runtime upgrade to Battery Station and Mainnet?

A: Pushing runtime upgrade to Battery Station and Mainnet ensures that the new release is deployed to the production environment and is stable. This step guarantees a smooth and successful deployment.

Q: Why is it necessary to create a draft release?

A: Creating a draft release ensures that the new release is properly documented and provides valuable information to developers and users. This step helps prevent potential conflicts and ensures that the new release is compatible with the existing infrastructure.

Q: What is the purpose of adding build artifacts?

A: Adding build artifacts ensures that developers have access to the necessary assets for development and testing. This step guarantees a smooth and successful deployment.

Q: Why is it essential to verify client version compatibility?

A: Verifying client version compatibility ensures that the new client versions have run on the network without issue for 12 hours. This step guarantees a smooth and successful deployment.

Q: What is the significance of verifying extrinsic ordering?

A: Verifying extrinsic ordering ensures that the ordering of pallets and extrinsics remains consistent. This step is critical for offline signing libraries and other dependent components.

Q: Why is it necessary to verify proxy filtering?

A:ifying proxy filtering ensures that the proxy filters are up to date to include any new calls in the new runtime. This step prevents potential security vulnerabilities and ensures that the new release is compatible with the existing proxy filters.

Q: What is the purpose of verifying benchmarks?

A: Verifying benchmarks ensures that the benchmarking suite has been run with the new runtime and any function weights have been updated if necessary. This step ensures that the new release is optimized for performance and provides accurate benchmarking results.

Q: Where can I find more information about the release checklist?

A: You can find more information about the release checklist in the Zeitgeist documentation. Additionally, you can reach out to the Zeitgeist team for further assistance and guidance.

Q: How can I contribute to the release checklist?

A: You can contribute to the release checklist by suggesting new checks or improving existing ones. Please submit your suggestions through the Zeitgeist GitHub repository. The Zeitgeist team will review and incorporate your suggestions into the release checklist.

Q: What is the next step after completing the release checklist?

A: After completing the release checklist, the next step is to deploy the new release to the production environment. This step guarantees a smooth and successful deployment and ensures that the new release is compatible with the existing infrastructure.

Q: How can I stay up-to-date with the latest developments and releases?

A: You can stay up-to-date with the latest developments and releases by following the Zeitgeist blog and Zeitgeist GitHub repository. Additionally, you can join the Zeitgeist community to connect with other developers and stay informed about the latest news and updates.