Bump frame-benchmarking-cli from polkadot-v1.9.0 to polkadot-v1.10.0

[dependabot]

Bumps frame-benchmarking-cli from polkadot-v1.9.0 to polkadot-v1.10.0.

Release notes

Sourced from frame-benchmarking-cli's releases.

Polkadot v1.10.0

This release contains the changes from polkadot-v1.9.0 to polkadot-v1.10.0.

Changelog

Changelog for Node Dev

#3521: Collator side changes for elastic scaling

Parachain teams wishing to utilize the benefits of elastic scaling will need to upgrade their collator code to include these changes.

#3302: Collator protocol changes for elastic scaling

This PR introduces changes to the collator protocol to support elastic scaling. Namely, a new variant added to the collation response to include parent head-data along with the collation. Currently, the new variant is not being used.

#3950: Add ClaimQueue wrapper

Intoduces a new wrapper type: ClaimQueueSnapshot. It contains a snapshot of the ClaimQueue at an arbitrary relay chain block. Two methods are exposed to allow access to the claims at specific depths.

#3795: Enable collators to build on multiple cores

Introduces a CoreIndex parameter in SubmitCollationParams. This enables the collators to make use of potentially multiple cores assigned at some relay chain block. This extra parameter is used by the collator protocol and collation generation subsystems to forward the collation to the approapriate backing group.

#3580: Expose ClaimQueue via a runtime api and consume it in collation-generation

Creates a new runtime api exposing the ClaimQueue from scheduler pallet. Consume the api in collation generation (if available) by getting what's scheduled on a core from the ClaimQueue instead of from next_up_on_available (from AvailabilityCores runtime api).

#3854: Export unified ParachainHostFunctions from cumulus-client-service

Exports ParachainHostFunctions to have a bundled version of SubstrateHostFunctions and cumulus_primitives_proof_size_hostfunction::storage_proof_size::HostFunctions. This increases discoverability and makes it more obvious that they should be used together in parachain nodes.

#3479: Elastic scaling: runtime dependency tracking and enactment

Adds support in the inclusion and paras_inherent runtime modules for backing and including multiple candidates of the same para if they form a chain.

Changelog for Runtime Dev

#3817: Parachain Runtime API Implementations into mod apis Refactoring

This PR introduces a refactoring to the runtime API implementations within the parachain template project. The primary changes include enhancing the visibility of RUNTIME_API_VERSIONS to pub in impl_runtime_apis.rs, centralizing API implementations in a new apis.rs file, and streamlining lib.rs. These changes aim to improve project structure, maintainability, and readability.

Key Changes:

• RUNTIME_API_VERSIONS is now publicly accessible, enhancing module-wide visibility.
• Introduction of apis.rs centralizes runtime API implementations, promoting a cleaner and more navigable project structure.
• The main runtime library file, lib.rs, has been updated to reflect these structural changes, removing redundant API implementations and simplifying runtime configuration by pointing VERSION to the newly exposed RUNTIME_API_VERSIONS from apis.rs.

... (truncated)

Changelog

Sourced from frame-benchmarking-cli's changelog.

Release

The outputs of a release are the polkadot and polkadot-parachain node binaries, the runtimes for Westend & Rococo and their system parachains, and new crate versions published to crates.io.

Setup

We have two branches: master and stable. master is the main development branch where normal Pull Requests are opened. Developers need to mostly only care about this branch.
The stable branch contains a version of the code that is ready to be released. Its contents are always audited. Merging to it is restricted to Backports.

Versioning

We are releasing multiple different things from this repository in one release, but we don't want to use the same version for everything. Thus, in the following we explain the versioning story for the crates, node and Westend & Rococo. To easily refer to a release, it shall be named by its date in the form stableYYMMDD.

Crate

We try to follow SemVer 2.0.0 as best as possible for versioning our crates. The definitions of major, minor and patch version for Rust crates are slightly altered from their standard for pre 1.0.0 versions. Quoting rust-lang.org:

Initial development releases starting with “0.y.z” can treat changes in “y” as a major release, and “z” as a minor release. “0.0.z” releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.

SemVer requires a piece of software to first declare a public API. The public API of the Polkadot SDK is hereby declared as the sum of all crates' public APIs.

Inductively, the public API of our library crates is declared as all public items that are neither:

• Inside a __private module
• Documented as "unstable" or "experimental" in the first line of docs
• Bear unstable or experimental in their absolute path

Node

The versioning of the Polkadot node is done most of the time by only incrementing the minor version. The major version is only bumped for special releases and the patch can be used for an out of band release that fixes some critical bug. The node version is not following SemVer. This means that the version doesn't express if there are any breaking changes in the CLI interface or similar. The node version is declared in the NODE_VERSION variable.

Westend & Rococo

For the these networks, in addition to incrementing the Cargo.toml version we also increment the spec_version and sometimes the transaction_version. The spec version is also following the node version. Its schema is: M_mmm_ppp and for example 1_002_000 is the node release 1.2.0. This versioning has no further meaning, and is only done to map

... (truncated)

Commits

• 7049c3c move prdocs to the release folder
• 7af3c71 Added support for coretime-kusama/polkadot and people-kusama/polkadot (#3961)
• ca2767c Bump spec_version
• 9938487 Bump crate versions in: cumulus/polkadot-parachain/Cargo.toml
• af0fa70 Bump node version to 1.10.0 in polkadot-cli
• 0f4e849 Add ClaimQueue wrapper (#3950)
• ecc51a2 Enable pov-reclaim on rococo and westend parachains (#3858)
• 287b116 chainHead: Ensure reasonable distance between leaf and finalized block (#3562)
• cdacfb9 Added tests for XCM barriers: AllowSubscriptions, WithUniqueTopic and `Tr...
• 9b378a2 sp-wasm-interface: wasmtime should not be enabled by std (#3954)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #11.