Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump sp-transaction-pool from polkadot-v1.9.0 to polkadot-v1.13.0 #7

Closed

Conversation

dependabot[bot]
Copy link

@dependabot dependabot bot commented on behalf of github Jun 14, 2024

Bumps sp-transaction-pool from polkadot-v1.9.0 to polkadot-v1.13.0.

Release notes

Sourced from sp-transaction-pool's releases.

Polkadot v1.13.0

This release contains the changes from polkadot-v1.12.0 to polkadot-v1.13.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.

#4431: Statement-Distribution validator disabling changes

In preparation for launching re-enabling (#2418), we need to adjust the disabling strategy of statement-distribution to use the relay parent's state instead of the latest state (union of active leaves). This will also ensure no raciness of getting the latest state vs accepting statements from disabling validators at the cost of being more lenient/potentially accepting more statements from disabled validators.

#4410: [sc-chain-spec] Remove deprecated code

The RuntimeGenesisConfig generic type parameter was removed from GenericChainSpec struct. ChainSpec::from_genesis method was removed. Removed related deprecated code from sc-chain-spec. This change simplifies the codebase and ensures the use of up-to-date definitions.

#4555: Move para_id to MockValidationDataInherentDataProvider

This moves the para_id from MockXcmConfig to MockValidationDataInherentDataProvider to make it more prominent. The para_id should be set to the parachain id of the parachain that gets mocked to ensure that the relay chain storage proof is setup correctly etc.

#4595: Remove elastic-scaling-experimental feature flag

The feature was masking the ability of collators to respond with CollationWithParentHeadData to validator collation fetch requests, a requirement for elastic scaling. Please note that CollationWithParentHeadData is only sent by collators of parachains with multiple cores assigned, otherwise collators must respond with CollationFetchingResponse::Collation

#1644: Add availability-recovery from systematic chunks

Implements polkadot-fellows/RFCs#47 and adds the logic for availability recovery from systematic chunks. The /req_chunk/1 req-response protocol is now considered deprecated in favour of /req_chunk/2. Systematic recovery is guarded by a configuration bit in the runtime (bit with index 2 of the node_features field from the HostConfiguration) and must not be enabled until all (or almost all) validators have upgraded to the node version that includes this PR.

#4471: Remove prospective-parachains subsystem from collator nodes

Removes the prospective-parachains subsystem from collators. The GetMinimumRelayParents of the implicit view is replaced by direct ChainAPI and runtime calls. The subsystem was causing performance problems when collating connected to an RPC node, due to the high number of runtime API calls, which were unneccessary for a collator.

#4198: Replace Multiaddr & related types with substrate-specific types

Introduce custom types / substrate wrappers for Multiaddr, multiaddr::Protocol, Multihash, ed25519::* and supplementary еypes like errors and iterators. Common code in substrate uses these custom types, while libp2p & litep2p network backends use their corresponding libraries types.

... (truncated)

Changelog

Sourced from sp-transaction-pool'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 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
  • d5160c1 Move prdoc to the release folder
  • 958792b Backport Append optimization to 1.13.0 (#4771)
  • 47ef2a0 Move prdoc to the release folder
  • 12f7aa7 [1.13.0 backport] finalization: Skip tree route calculation if no forks prese...
  • 13a7ae7 Update Cargo.lock
  • a8eac6d fix build on MacOS: bump secp256k1 and secp256k1-sys to patched versions (#4709)
  • 7725331 Bump rococo-parachain spec_version
  • bc8eb46 Reordering prdocs for the release 1.13.0
  • 7418876 Bump spec_version to 1_013_000
  • 05f150f Bump crate versions in: cumulus/polkadot-parachain/Cargo.toml
  • 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 dependabot bot added dependencies Pull requests that update a dependency file rust Pull requests that update Rust code labels Jun 14, 2024
@dependabot dependabot bot force-pushed the dependabot/cargo/sp-transaction-pool-polkadot-v1.13.0 branch 3 times, most recently from fb5d04a to e21b774 Compare June 23, 2024 20:24
Bumps [sp-transaction-pool](https://github.com/paritytech/polkadot-sdk) from polkadot-v1.9.0 to polkadot-v1.13.0.
- [Release notes](https://github.com/paritytech/polkadot-sdk/releases)
- [Changelog](https://github.com/paritytech/polkadot-sdk/blob/master/docs/RELEASE.md)
- [Commits](paritytech/polkadot-sdk@3c3d6fc...d5160c1)

---
updated-dependencies:
- dependency-name: sp-transaction-pool
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>
@dependabot dependabot bot force-pushed the dependabot/cargo/sp-transaction-pool-polkadot-v1.13.0 branch from e21b774 to 0bf150e Compare June 30, 2024 20:30
Copy link
Author

dependabot bot commented on behalf of github Jul 3, 2024

Superseded by #15.

@dependabot dependabot bot closed this Jul 3, 2024
@dependabot dependabot bot deleted the dependabot/cargo/sp-transaction-pool-polkadot-v1.13.0 branch July 3, 2024 10:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file rust Pull requests that update Rust code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants