Bump pallet-nfts from polkadot-v1.6.0 to polkadot-v1.11.0

[dependabot]

Bumps pallet-nfts from polkadot-v1.6.0 to polkadot-v1.11.0.

Release notes

Sourced from pallet-nfts's releases.

Polkadot v1.11.0

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

Changelog

Changelog for Node Dev

These changes are relevant to: Those who build around the client side code. Alternative client builders, SMOLDOT, those who consume RPCs. These are people who are oblivious to the runtime changes. They only care about the meta-protocol, not the protocol itself.

#4059: Remove redundent logging code

Simplified logging code, now does slightly less work while logging.

#4027: Add candidates_pending_availability Runtime API

This new API retrieves all CommittedCandidateReceipts of all candidates pending availability for a parachain at a given relay chain block number. It is required by collators that make use of elastic scaling capability in the context of PoV recovery and block import. The old API candidate_pending_availability is now deprectated and will be removed in the future.

#3979: Deprecate para_id() from CoreState in polkadot primitives

CoreState's para_id() function is getting deprecated in favour of direct usage of the ClaimQueue. This is the preferred approach because it provides a better view on what is scheduled on each core.

#4169: Stabilize transactionBroadcast RPC class to version 1

The transactionBroadcast RPC API is stabilized to version 1.

#3953: Adapt RemoteExternalities and its related types to be used with generic hash parameters

Modify RemoteExternalities, Mode, OnlineConfig andSnapshot to rely now on generic parameter, instead of BlockT. Adjust in consequence their implementation to be compatible with types Hash, or if possible any generic. Adapt Builder struct and implementation for these bounds.

#4171: Stabilize transactionWatch RPC class to version 1

The transactionWatch RPC API is stabilized to version 1.

#3512: [FRAME] Introduce Runtime Omni Bencher

Introduces a new freestanding binary; the frame-omni-bencher. This can be used as alternative to the node-integrated benchmark pallet command. It currently only supports pallet benchmarking.

The optional change to integrate this MR is in the node. The run function is now deprecated in favour or run_with_spec. This should be rather easy to integrate:

runner.sync_run(|config| cmd
-    .run::<HashingFor<Block>, ReclaimHostFunctions>(config)
+    .run_with_spec::<HashingFor<Block>, ReclaimHostFunctions>(Some(config.chain_spec))
)

Additionally, a new --runtime CLI arg was introduced to the benchmark pallet command. It allows to generate the genesis state directly by the runtime, instead of using a spec file.

... (truncated)

Changelog

Sourced from pallet-nfts'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

• 0bb6249 Bump transaction_version
• 49b27c7 add environment var to the matrix job
• 082e23e Update Cargo.lock
• 0d65b3f Move prdocs to the release folder
• a85bdb5 Bump spec_version
• 168bccb Bump crate versions in: cumulus/polkadot-parachain/Cargo.toml
• 3fe1c9f Bump node version to 1.11.0 in polkadot-cli
• 4f3d43a Revert execute_blob and send_blob (#4266)
• d29c363 Updated review-bot to obtain number from event (#4271)
• ac473cf AllowHrmpNotificationsFromRelayChain barrier for HRMP notifications from th...
• 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 #18.