Skip to content
Snippets Groups Projects
  1. Dec 14, 2023
  2. Dec 13, 2023
    • Marcin S.'s avatar
    • Egor_P's avatar
      fix docker tag for polkadot image (#2702) · 30151bd3
      Egor_P authored
      This PR has a tiny fix for the proper creation of the tag for the
      pokadot's docker tag.
    • Gonçalo Pestana's avatar
      [Staking] Adds a round check at signed solution submission (#2690) · cc846cc2
      Gonçalo Pestana authored
      This PR adds a round check to the `Call::submit` extrinsic to make sure
      that the solution submission has been prepared for the current election
      round and avoid penalties for delayed submissions.
      
      Related to
      https://github.com/paritytech-secops/srlabs_findings/issues/329
      
      ---------
      
      Co-authored-by: command-bot <>
    • dependabot[bot]'s avatar
      Bump toml from 0.7.6 to 0.8.2 (#2685) · 6ff50526
      dependabot[bot] authored
      
      Bumps [toml](https://github.com/toml-rs/toml) from 0.7.6 to 0.8.2.
      <details>
      <summary>Commits</summary>
      <ul>
      <li><a
      href="https://github.com/toml-rs/toml/commit/fe65b2bfa2021b939a0fc71e8b008609ea21f6fe"><code>fe65b2b</code></a>
      chore: Release</li>
      <li><a
      href="https://github.com/toml-rs/toml/commit/ed597ebad11afdadc27712e3f851e6c5cd48fb51"><code>ed597eb</code></a>
      chore: Release</li>
      <li><a
      href="https://github.com/toml-rs/toml/commit/257a0fdc59656c01bcce151af61339563fac22c4"><code>257a0fd</code></a>
      docs: Update changelog</li>
      <li><a
      href="https://github.com/toml-rs/toml/commit/4b44f53a3194729317250232872584464ebe12a7"><code>4b44f53</code></a>
      Merge pull request <a
      href="https://redirect.github.com/toml-rs/toml/issues/617">#617</a> from
      epage/update</li>
      <li><a
      href="https://github.com/toml-rs/toml/commit/7eaf2861106430833eb40e7b237fe5522be6bb03"><code>7eaf286</code></a>
      fix(parser): Failed on mixed inline tables</li>
      <li><a
      href="https://github.com/toml-rs/toml/commit/e1f20378a2a8c78f182b2ac61f76eebd30990b77"><code>e1f2037</code></a>
      test: Verify with latest data</li>
      <li><a
      href="https://github.com/toml-rs/toml/commit/2f9253c9eb6c968be8227284b873660bd3451007"><code>2f9253c</code></a>
      chore: Update toml-test</li>
      <li><a
      href="https://github.com/toml-rs/toml/commit/c9b481cab5038e9801e60f6bfb935f983218d8f6"><code>c9b481c</code></a>
      test(toml): Ensure tables are used for validation</li>
      <li><a
      href="https://github.com/toml-rs/toml/commit/43d7f29cfdad91bb72658d94039b16e7457a54ed"><code>43d7f29</code></a>
      Merge pull request <a
      href="https://redirect.github.com/toml-rs/toml/issues/615">#615</a> from
      toml-rs/renovate/actions-checkout-4.x</li>
      <li><a
      href="https://github.com/toml-rs/toml/commit/ef9b8372c86f84481e8439c9c4a1f5dc4c15c35e"><code>ef9b837</code></a>
      chore(deps): update actions/checkout action to v4</li>
      <li>Additional commits viewable in <a
      href="https://github.com/toml-rs/toml/compare/toml-v0.7.6...toml-v0.8.2">compare
      view</a></li>
      </ul>
      </details>
      <br />
      
      
      [![Dependabot compatibility
      score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=toml&package-manager=cargo&previous-version=0.7.6&new-version=0.8.2)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
      
      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-automerge-start)
      [//]: # (dependabot-automerge-end)
      
      ---
      
      <details>
      <summary>Dependabot commands and options</summary>
      <br />
      
      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 <dependency name> major version` will close this
      group update PR and stop Dependabot creating any more for the specific
      dependency's major version (unless you unignore this specific
      dependency's major version or upgrade to it yourself)
      - `@dependabot ignore <dependency name> minor version` will close this
      group update PR and stop Dependabot creating any more for the specific
      dependency's minor version (unless you unignore this specific
      dependency's minor version or upgrade to it yourself)
      - `@dependabot ignore <dependency name>` will close this group update PR
      and stop Dependabot creating any more for the specific dependency
      (unless you unignore this specific dependency or upgrade to it yourself)
      - `@dependabot unignore <dependency name>` will remove all of the ignore
      conditions of the specified dependency
      - `@dependabot unignore <dependency name> <ignore condition>` will
      remove the ignore condition of the specified dependency and ignore
      conditions
      
      
      </details>
      
      Signed-off-by: default avatardependabot[bot] <support@github.com>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
    • Squirrel's avatar
      Set clippy lints in workspace (requires rust 1.74) (#2390) · be8e6268
      Squirrel authored
      
      We currently use a bit of a hack in `.cargo/config` to make sure that
      clippy isn't too annoying by specifying the list of lints.
      
      There is now a stable way to define lints for a workspace. The only down
      side is that every crate seems to have to opt into this so there's a
      *few* files modified in this PR.
      
      Dependencies:
      
      - [x] PR that upgrades CI to use rust 1.74 is merged.
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <25483142+joepetrowski@users.noreply.github.com>
      Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
      Co-authored-by: default avatarLiam Aharon <liam.aharon@hotmail.com>
    • Branislav Kontur's avatar
      Updated benchmarks related to the Rococo/Westend bridge (#2639) · 4c4407a8
      Branislav Kontur authored
      Co-authored-by: command-bot <>
    • gupnik's avatar
    • Svyatoslav Nikolsky's avatar
      Tests for BridgeHub(s) <> remote GRANDPA chain (#2692) · 9ecb2d33
      Svyatoslav Nikolsky authored
      So far the `bridge-hub-test-utils` contained a tests set for testing
      BridgeHub runtime that is bridging with the remote **parachain**. But we
      have https://github.com/paritytech/polkadot-sdk/pull/2540 coming, which
      would add Rococo <> Bulletin chain bridge (where Bulletin = standalone
      chain that is using GRANDPA finality). Then it'll be expanded to
      Polkadot BH as well.
      
      So this PR adds the same set of tests to the `bridge-hub-test-utils`,
      but for the case when remote chain is the chain with GRANDPA finality.
      There's a lot of changes in this PR - I'll describe some:
      - I've added `BasicParachainRuntime` trait to decrease number of lines
      we need to add to `where` clause. Could revert, but imo it is useful;
      - `cumulus/parachains/runtimes/bridge-hubs/test-utils/src/test_data` is
      a submodule for generating test data for the test sets.
      `from_parachain.rs` is used in tests for the case when remote chain is a
      parachain, `from_grandpa_chain.rs` - for the bridges with remote GRANDPA
      chains. `mod.rs` has some code, shared by both types of tests;
      - `cumulus/parachains/runtimes/bridge-hubs/test-utils/src/test_data` is
      a submodule with all test cases. The `mod.rs` has tests, suitable for
      all cases. There's also `wth_parachain.rs` and `with_grandpa_chain.rs`
      with the same meaning as above;
      - I've merged the "core" code of two previous tests -
      `relayed_incoming_message_works` and `complex_relay_extrinsic_works`
      into one single `relayed_incoming_message_works` test. So now we are
      always constructing extrinsics and are dispatching them using executive
      module (meaning all signed extensions are also tested).
      
      New test set is used here:
      https://github.com/paritytech/polkadot-sdk/pull/2540. Once this PR is
      merged, I'll merge that other PR with master to remove duplicate
      changes.
      
      I'm also planning to cleanup generic constraints + remove some
      unnecessary assumptions about used chains in a follow-up PRs. But for
      now I think this PR has enough changes, so don't want to complicate it
      even more.
      
      ---
      
      Breaking changes for the code that have used those tests before:
      - the `construct_and_apply_extrinsic` callback now accepts the
      `RuntimeCall` instead of the `pallet_utility::Call`;
      - the `construct_and_apply_extrinsic` now may be called multiple times
      for the single test, so make sure the `frame_system::CheckNonce` is
      correctly constructed;
      - all previous tests have been moved from
      `bridge_hub_test_utils::test_cases` to
      `bridge_hub_test_utils::test_cases::from_parachain` module;
      - there are several changes in test arguments - please refer to
      https://github.com/paritytech/polkadot-sdk/compare/sv-tests-for-bridge-with-remote-grandpa-chain?expand=1#diff-79a28d4d3e1749050341c2424f00c4c139825b1a20937767f83e58b95166735c
      for details.
    • Chevdor's avatar
      Add `check runtimes` GH Workflow (#2252) · 3c5fcbe6
      Chevdor authored
      This PR introduces:
      - a new script 
      - a new GH Workflow 
      - runtime reference spec files for `rococo` and `westend`
      
      It brings a mechanism to check that part(s) of the runtimes' metadata
      that should not change over time, actually did not change over time.
      
      Ideally, the GHW should trigger when a release is edited but GH seem to
      [have an issue](https://github.com/orgs/community/discussions/47794)
      that prevents the trigger from working. This is why the check has been
      implemented as `workflow_dispatch` for a start.
      
      The `workflow_dispatch` requires a `release_id` that can be found using:
      ```
      curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
         https://api.github.com/repos/paritytech/polkadot-sdk/releases | \
         jq '.[] | { name: .name, id: .id }'
      ```
      as documented in the workflow.
      
      A sample run can be seen
      [here](https://github.com/chevdor/polkadot-sdk/actions/runs/6811176342).
    • Joshy Orndorff's avatar
      Rename `ExportGenesisStateCommand` to `ExportGenesisHeadCommand` and make it... · 8683bbee
      Joshy Orndorff authored
      Rename `ExportGenesisStateCommand` to `ExportGenesisHeadCommand` and make it respect custom genesis block builders (#2331)
      
      Closes #2326.
      
      This PR both fixes a logic bug and replaces an incorrect name.
      
      ## Bug Fix: Respecting custom genesis builder
      
      Prior to this PR the standard logic for creating a genesis block was
      repeated inside of cumulus. This PR removes that duplicated logic, and
      calls into the proper `BuildGenesisBlock` implementation.
      
      One consequence is that if the genesis block has already been
      initialized, it will not be re-created, but rather read from the
      database like it is for other node invocations. So you need to watch out
      for old unpurged data during the development process. Offchain tools may
      need to be updated accordingly. I've already filed
      https://github.com/paritytech/zombienet/issues/1519
      
      
      
      ## Rename: It doesn't export state. It exports head data.
      
      The name export-genesis-state was always wrong, nad it's never too late
      to right a wrong. I've changed the name of the struct to
      `ExportGenesisHeadCommand`.
      
      There is still the question of what to do with individual nodes' public
      CLIs. I have updated the parachain template to a reasonable default that
      preserves compatibility with tools that will expect
      `export-genesis-state` to still work. And I've chosen not to modify the
      public CLIs of any other nodes in the repo. I'll leave it up to their
      individual owners/maintains to decide whether that is appropriate.
      
      ---------
      
      Co-authored-by: default avatarJoshy Orndorff <git-user-email.h0ly5@simplelogin.com>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Co-authored-by: default avatarBastian Köcher <info@kchr.de>
    • Alexandru Gheorghe's avatar
      Approve multiple candidates with a single signature (#1191) · a84dd0db
      Alexandru Gheorghe authored
      Initial implementation for the plan discussed here: https://github.com/paritytech/polkadot-sdk/issues/701
      Built on top of https://github.com/paritytech/polkadot-sdk/pull/1178
      v0: https://github.com/paritytech/polkadot/pull/7554,
      
      ## Overall idea
      
      When approval-voting checks a candidate and is ready to advertise the
      approval, defer it in a per-relay chain block until we either have
      MAX_APPROVAL_COALESCE_COUNT candidates to sign or a candidate has stayed
      MAX_APPROVALS_COALESCE_TICKS in the queue, in both cases we sign what
      candidates we have available.
      
      This should allow us to reduce the number of approvals messages we have
      to create/send/verify. The parameters are configurable, so we should
      find some values that balance:
      
      - Security of the network: Delaying broadcasting of an approval
      shouldn't but the finality at risk and to make sure that never happens
      we won't delay sending a vote if we are past 2/3 from the no-show time.
      - Scalability of the network: MAX_APPROVAL_COALESCE_COUNT = 1 &
      MAX_APPROVALS_COALESCE_TICKS =0, is what we have now and we know from
      the measurements we did on versi, it bottlenecks
      approval-distribution/approval-voting when increase significantly the
      number of validators and parachains
      - Block storage: In case of disputes we have to import this votes on
      chain and that increase the necessary storage with
      MAX_APPROVAL_COALESCE_COUNT * CandidateHash per vote. Given that
      disputes are not the normal way of the network functioning and we will
      limit MAX_APPROVAL_COALESCE_COUNT in the single digits numbers, this
      should be good enough. Alternatively, we could try to create a better
      way to store this on-chain through indirection, if that's needed.
      
      ## Other fixes:
      - Fixed the fact that we were sending random assignments to
      non-validators, that was wrong because those won't do anything with it
      and they won't gossip it either because they do not have a grid topology
      set, so we would waste the random assignments.
      - Added metrics to be able to debug potential no-shows and
      mis-processing of approvals/assignments.
      
      ## TODO:
      - [x] Get feedback, that this is moving in the right direction. @ordian
      @sandreim @eskimor
      
       @burdges, let me know what you think.
      - [x] More and more testing.
      - [x]  Test in versi.
      - [x] Make MAX_APPROVAL_COALESCE_COUNT &
      MAX_APPROVAL_COALESCE_WAIT_MILLIS a parachain host configuration.
      - [x] Make sure the backwards compatibility works correctly
      - [x] Make sure this direction is compatible with other streams of work:
      https://github.com/paritytech/polkadot-sdk/issues/635 &
      https://github.com/paritytech/polkadot-sdk/issues/742
      - [x] Final versi burn-in before merging
      
      ---------
      
      Signed-off-by: default avatarAlexandru Gheorghe <alexandru.gheorghe@parity.io>
  3. Dec 12, 2023
    • Branislav Kontur's avatar
      [ci] Add `-D warnings` for `cargo-check-each-crate` job to fail on warnings (#2670) · d18a682b
      Branislav Kontur authored
      ## Summary
      
      This PR turns on `-D warnings` for `cargo-check-each-crate job` job to
      fail on warnings e.g. like this:
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673130
      
      Before this PR, there was a warning and `cargo-check-each-crate` job did
      not fail:
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4641444
      ```
      warning: unused import: `ToTokens`
        --> substrate/primitives/api/proc-macro/src/utils.rs:22:34
         |
      22 | use quote::{format_ident, quote, ToTokens};
         |                                  ^^^^^^^^
         |
         = note: `#[warn(unused_imports)]` on by default
      warning: `sp-api-proc-macro` (lib) generated 1 warning (run `cargo fix --lib -p sp-api-proc-macro` to apply 1 suggestion)
      ```
      
      Fixes on the way:
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4641444
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673265
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673410
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673681
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673836
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673941
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4674256
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4679328
      
      
      
      ## Questions
      - [ ] why does this check triggers only `cargo check --locked`?
      `--all-features` or `--all-targets` are not needed? Or aren't they
      avoided intentionally?
      
      ---------
      
      Co-authored-by: command-bot <>
    • Parth's avatar
      Make crate visible methods of `OverlayedChanges` public (#2597) · 0470bd68
      Parth authored
      
      # Description
      
      - What does this PR do?
      This PR make some methods of `OverlayedChanges` public which were
      previously only visible in same crate.
      - Why are these changes needed?
      Since, some methods of the `OverlayedChanges` only have crate level
      visibility, which makes `OverlayedChanges` somewhat unusable outside the
      crate to create custom implementation of `Externalities`. We make those
      method public to enable `OverlayedChanges` to remedy this.
      - How were these changes implemented and what do they affect?
      Changes are implemented by replacing crate visibility to public
      visibility of 4 functions.
      
      
      # Checklist
      
      - [x] My PR includes a detailed description as outlined in the
      "Description" section above
      - [ ] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
      of this project (at minimum one label for `T`
        required)
      - [ ] I have made corresponding changes to the documentation (if
      applicable)
      - [ ] I have added tests that prove my fix is effective or that my
      feature works (if applicable)
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
    • Egor_P's avatar
      Update prdoc (#2697) · d43d2fe2
      Egor_P authored
      Small update of the title in one of the prdoc files
    • Francisco Aguirre's avatar
      Fix ParentOrSiblings (#2428) · 313b2c4b
      Francisco Aguirre authored
      
      We were not filtering for sibling parachains, but for sibling anything
      
      ---------
      
      Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
      Co-authored-by: command-bot <>
    • Branislav Kontur's avatar
      Ensure xcm versions over bridge (on sending chains) (#2481) · 575b8f8d
      Branislav Kontur authored
      ## Summary
      
      This pull request proposes a solution for improved control of the
      versioned XCM flow over the bridge (across different consensus chains)
      and resolves the situation where the sending chain/consensus has already
      migrated to a higher XCM version than the receiving chain/consensus.
      
      ## Problem/Motivation
      
      The current flow over the bridge involves a transfer from AssetHubRococo
      (AHR) to BridgeHubRococo (BHR) to BridgeHubWestend (BHW) and finally to
      AssetHubWestend (AHW), beginning with a reserve-backed transfer on AHR.
      
      In this process:
      1. AHR sends XCM `ExportMessage` through `XcmpQueue`, incorporating XCM
      version checks using the `WrapVersion` feature, influenced by
      `pallet_xcm::SupportedVersion` (managed by
      `pallet_xcm::force_xcm_version` or version discovery).
      
      2. BHR handles the `ExportMessage` instruction, utilizing the latest XCM
      version. The `HaulBlobExporter` converts the inner XCM to
      [`VersionedXcm::from`](https://github.com/paritytech/polkadot-sdk/blob/63ac2471aa0210f0ac9903bdd7d8f9351f9a635f/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465-L467),
      also using the latest XCM version.
      
      However, challenges arise:
      - Incompatibility when BHW uses a different version than BHR. For
      instance, if BHR migrates to **XCMv4** while BHW remains on **XCMv3**,
      BHR's `VersionedXcm::from` uses `VersionedXcm::V4` variant, causing
      encoding issues for BHW.
        ```
      	/// Just a simulation of possible error, which could happen on BHW
      	/// (this code is based on actual master without XCMv4)
      	let encoded = hex_literal::hex!("0400");
      	println!("{:?}", VersionedXcm::<()>::decode(&mut &encoded[..]));
      
      Err(Error { cause: None, desc: "Could not decode `VersionedXcm`, variant
      doesn't exist" })
        ``` 
      - Similar compatibility issues exist between AHR and AHW.
      
      ## Solution
      
      This pull request introduces the following solutions:
      
      1. **New trait `CheckVersion`** - added to the `xcm` module and exposing
      `pallet_xcm::SupportedVersion`. This enhancement allows checking the
      actual XCM version for desired destinations outside of the `pallet_xcm`
      module.
      
      2. **Version Check in `HaulBlobExporter`** uses `CheckVersion` to check
      known/configured destination versions, ensuring compatibility. For
      example, in the scenario mentioned, BHR can store the version `3` for
      BHW. If BHR is on XCMv4, it will attempt to downgrade the message to
      version `3` instead of using the latest version `4`.
      
      3. **Version Check in `pallet-xcm-bridge-hub-router`** - this check
      ensures compatibility with the real destination's XCM version,
      preventing the unnecessary sending of messages to the local bridge hub
      if versions are incompatible.
      
      These additions aim to improve the control and compatibility of XCM
      flows over the bridge and addressing issues related to version
      mismatches.
      
      ## Possible alternative solution
      
      _(More investigation is needed, and at the very least, it should extend
      to XCMv4/5. If this proves to be a viable option, I can open an RFC for
      XCM.)._
      
      Add the `XcmVersion` attribute to the `ExportMessage` so that the
      sending chain can determine, based on what is stored in
      `pallet_xcm::SupportedVersion`, the version the destination is using.
      This way, we may not need to handle the version in `HaulBlobExporter`.
      
      ```
      ExportMessage {
      	network: NetworkId,
      	destination: InteriorMultiLocation,
      	xcm: Xcm<()>
      	destination_xcm_version: Version, // <- new attritbute
      },
      ```
      
      ```
      pub trait ExportXcm {
              fn validate(
      		network: NetworkId,
      		channel: u32,
      		universal_source: &mut Option<InteriorMultiLocation>,
      		destination: &mut Option<InteriorMultiLocation>,
      		message: &mut Option<Xcm<()>>,
                      destination_xcm_version: Version, , // <- new attritbute
      	) -> SendResult<Self::Ticket>;
      ```
      
      ## Future Directions
      
      This PR does not fix version discovery over bridge, further
      investigation will be conducted here:
      https://github.com/paritytech/polkadot-sdk/issues/2417.
      
      ## TODO
      
      - [x] `pallet_xcm` mock for tests uses hard-coded XCM version `2` -
      change to 3 or lastest?
      - [x] fix `pallet-xcm-bridge-hub-router`
      - [x] fix HaulBlobExporter with version determination
      [here](https://github.com/paritytech/polkadot-sdk/blob/2183669d05f9b510f979a0cc3c7847707bacba2e/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465)
      - [x] add unit-tests to the runtimes
      - [x] run benchmarks for `ExportMessage`
      - [x] extend local run scripts about `force_xcm_version(dest, version)`
      - [ ] when merged, prepare governance calls for Rococo/Westend
      - [ ] add PRDoc
      
      Part of: https://github.com/paritytech/parity-bridges-common/issues/2719
      
      ---------
      
      Co-authored-by: command-bot <>
    • Chevdor's avatar
      Changelogs local generation (#1411) · 42a3afba
      Chevdor authored
      
      This PR introduces a script and some templates to use the prdoc involved
      in a release and build:
      - the changelog
      - a simple draft of audience documentation
      
      Since the prdoc presence was enforced in the middle of the version
      1.5.0, not all PRs did come with a `prdoc` file.
      This PR creates all the missing `prdoc` files with some minimum content
      allowing to properly generate the changelog.
      The generated content is **not** suitable for the audience
      documentation.
      
      The audience documentation will be possible with the next version, when
      all PR come with a proper `prdoc`.
      
      ## Assumptions
      
      - the prdoc files for release `vX.Y.Z` have been moved under
      `prdoc/X.Y.Z`
      - the changelog requires for now for the prdoc files to contain author +
      topic. Thos fields are optional.
      
      The build script can  be called as:
      ```
      VERSION=X.Y.Z ./scripts/release/build-changelogs.sh
      ```
      
      Related:
      -  #1408
      
      ---------
      
      Co-authored-by: default avatarEgorPopelyaev <egor@parity.io>
    • juangirini's avatar
      Add a deprecation section to the Contributing notes (#2248) · 6b5995ff
      juangirini authored
      A brief explanation of the Deprecation Checklist is added to the
      Contributing notes with a link to it
    • Bastian Köcher's avatar
Loading