pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-09 20:11:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

Markdown linter (#1309)

Browse Source 
* Add markdown linting

- add linter default rules
- adapt rules to current code
- fix the code for linting to pass
- add CI check

fix #1243

* Fix markdown for Substrate
* Fix tooling install
* Fix workflow
* Add documentation
* Remove trailing spaces
* Update .github/.markdownlint.yaml

Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Fix mangled markdown/lists
* Fix captalization issues on known words
This commit is contained in:
Chevdor
2023-09-04 11:02:32 +02:00
committed by GitHub
parent 830fde2a60
commit a30092ab42
271 changed files with 6289 additions and 4450 deletions
Download Patch File Download Diff File Expand all files Collapse all files
substrate/docs/CHANGELOG.md
+61 -79
View File
@@ -8,24 +8,36 @@ The format is based on [Keep a Changelog].
## 2.0.1-> 3.0.0 - Apollo 14
Most notably, this is the first release of the new FRAME (2.0) with its new macro-syntax and some changes in types, and pallet versioning. This release also incorporates the faster and improve version 2.0 of the parity-scale-codec and upgraded dependencies all-around. While the `FinalityTracker` pallet has been dropped, this release marks the first public appearance of a few new pallets, too;Bounties, Lottery, Tips (extracted from the `Treasury`-pallet, see #7536) and Merkle-Mountain-Ranges (MMR).
Most notably, this is the first release of the new FRAME (2.0) with its new macro-syntax and some changes in types, and
pallet versioning. This release also incorporates the faster and improve version 2.0 of the `parity-scale-codec` and
upgraded dependencies all-around. While the `FinalityTracker` pallet has been dropped, this release marks the first
public appearance of a few new pallets, too;Bounties, Lottery, Tips (extracted from the `Treasury`-pallet, see #7536)
and Merkle-Mountain-Ranges (MMR).
On the client side, the most notable changes are around the keystore, making it async and switching to a different signing model allowing for remote-signing to be implemented; and various changes to improve networking and light-client support, like adding the Grandpa warp sync request-response protocol (#7711).
On the client side, the most notable changes are around the keystore, making it async and switching to a different
signing model allowing for remote-signing to be implemented; and various changes to improve networking and light-client
support, like adding the Grandpa warp sync request-response protocol (#7711).
_Contracts_: Please note that the contracts pallet _is not part_ of this release. The pallet is not yet ready and will be released separately in the coming weeks. The currently released contracts pallet _is not compatible_ with the new FRAME, thus if you need the contracts pallet, we recommend you wait with the upgrade until it has been released, too.
_Contracts_: Please note that the contracts pallet _is not part_ of this release. The pallet is not yet ready and will
be released separately in the coming weeks. The currently released contracts pallet _is not compatible_ with the new
FRAME, thus if you need the contracts pallet, we recommend you wait with the upgrade until it has been released, too.
### Upgrade instructions
Not too much has changed on the top and API level for developing Substrate between 2.0 and 3.0. The easiest and quickest path for upgrading is just to take the latest node-template and try applying your changes to it:
Not too much has changed on the top and API level for developing Substrate between 2.0 and 3.0. The easiest and quickest
path for upgrading is just to take the latest node-template and try applying your changes to it:
1. take a diff between 2.0 and your changes
2. store that diff
3. remove everything, copy over the 3.0 node-template
4. try re-applying your diff, manually, a hunk at a time.
If that doesn't work for you, we are working on an in-depth-guide for all major changes that took place and how you need to adapt your code for it. [You can find the upgrade guide under `docs/` in the repo](https://github.com/paritytech/substrate/blob/master/docs/Upgrading-2.0-to-3.0.md), if you have further questions or problem, please [feel free to ask in the github discussion board](https://github.com/paritytech/substrate/discussions).
If that doesn't work for you, we are working on an in-depth-guide for all major changes that took place and how you need
to adapt your code for it. [You can find the upgrade guide under `docs/` in the
repo](https://github.com/paritytech/substrate/blob/master/docs/Upgrading-2.0-to-3.0.md), if you have further questions
or problem, please [feel free to ask in the github discussion
board](https://github.com/paritytech/substrate/discussions).
Runtime
-------
#### Runtime
* contracts: Charge rent for code storage (#7935)
* contracts: Emit event on contract termination (#8014)
@@ -63,8 +75,7 @@ Runtime
* Move proxies migration (#7205)
* Introduce `cancel_proposal` to rid us of those pesky proposals (#7111)
Client
------
#### Client
* Remove backwards-compatibility networking hack (#8068)
* Extend SS58 network identifiers (#8039)
@@ -97,8 +108,7 @@ Client
* Refactor CurrencyToVote (#6896)
* client/network: Stop sending noise legacy handshake (#7211)
API
---
#### API
* pallet macro: easier syntax for `#[pallet::pallet]` with `struct Pallet<T>(_)` (#8091)
* WasmExecutor takes a cache directory (#8057)
@@ -106,7 +116,7 @@ API
* Migrate assets pallet to new macros (#7984)
* contracts: Make ChainExtension trait generic over the runtime (#8003)
* Decouple the session validators from im-online (#7127)
* Update parity-scale-codec to 2.0 (#7994)
* Update `parity-scale-codec` to 2.0 (#7994)
* Merkle Mountain Range pallet improvements (#7891)
* Cleaner GRANDPA RPC API for proving finality (#7339)
* Migrate frame-system to pallet attribute macro (#7898)
@@ -136,8 +146,7 @@ API
* SystemOrigin trait (#7226)
* permit setting treasury pallet initial funding through genesis (#7214)
Runtime Migrations
------------------
#### Runtime Migrations
* Migrate assets pallet to new macros (#7984)
* Fix elections-phragmen and proxy issue (#7040)
@@ -149,8 +158,7 @@ Runtime Migrations
## 2.0.0-> 2.0.1
Patch release with backports to fix broken nightly builds.
Namely contains backports of
Patch release with backports to fix broken nightly builds. Namely contains backports of
* [#7381: Make Substrate compile with latest nightly](https://github.com/paritytech/substrate/pull/7381)
* [#7238: Fix compilation with environmental on latest nightly](https://github.com/paritytech/substrate/pull/7238)
@@ -161,8 +169,7 @@ Namely contains backports of
## 2.0.0-rc6 -> 2.0.0 – two dot 😮
Runtime
-------
### Runtime
* Rename `ModuleToIndex` to `PalletRuntimeSetup` (#7148)
* Bounties (#5715)
@@ -174,8 +181,7 @@ Runtime
* Time-delay proxies (#6770)
* Refcounts are now u32 (#7164)
Client
------
### Client
* Rename `inspect-key` to `inspect` (#7160)
* Send import notification always for re-orgs (#7118)
@@ -190,8 +196,7 @@ Client
* Fix benchmark read/write key tracker for keys in child storages. (#6905)
* *: Update to next libp2p version 0.24.0 (#6891)
API
---
### API
* grandpa-rpc: use FinalityProofProvider to check finality for rpc (#6215)
* pow: replace the thread-base mining loop with a future-based mining worker (#7060)
@@ -204,16 +209,14 @@ API
* Add a `LightSyncState` field to the chain spec (#6894)
* *: Update to next libp2p version 0.24.0 (#6891)
Runtime Migrations
------------------
### Runtime Migrations
* Time-delay proxies (#6770)
## 2.0.0-rc5 -> 2.0.0-rc6 – Rock Hyrax
Runtime
-------
### Runtime
* Custom Codec Implementation for NPoS Election (#6720)
* Successful `note_imminent_preimage` is free (#6793)
@@ -224,8 +227,7 @@ Runtime
* pallet-evm: add support for tuple-based precompile declarations (#6681)
* grandpa: allow noting that the set has stalled (#6725)
Client
------
#### Client
* Merge Subkey into sc-cli (#4954)
* RpcHandlers Refactorings (#6846)
@@ -239,8 +241,7 @@ Client
* Name all the tasks! (#6726)
* Child nodes can be handled by adding a child `TaskManager` to the parent's `TaskManager` (#6771)
API
---
### API
* pow: add access to pre-digest for algorithm verifiers (#6900)
* babe, aura, pow: only call check_inherents if authoring version is compatible (#6862)
@@ -254,8 +255,7 @@ API
## 2.0.0-rc4 -> 2.0.0-rc5 – River Dolphin
Runtime
-------
### Runtime
* Support using system storage directly for EVM balance and nonce (#6659)
* Properly filter out duplicate voters in elections. (#6693)
@@ -273,14 +273,13 @@ Runtime
* pallet-evm: customizable chain id (#6537)
* Refactor as_sub to make things clearer. (#6503)
Client
------
### Client
* Update wasmtime to (almost) latest master (#6662)
* Update to latest sysinfo prevents leaking fd-handlers (#6708)
* Tracing values (#6679)
* Graceful shutdown for the task manager (#6654)
* Update substrate-networking Grafana dashboard (#6649)
* Update `substrate-networking` Grafana dashboard (#6649)
* *: Update to libp2p v0.21.1 (#6559)
* Send Status message on all newly-opened legacy substreams (#6593)
* babe: report equivocations (#6362)
@@ -288,8 +287,7 @@ Client
* Remove the service, replacing it with a struct of individual chain components (#6352)
* Fix tx-pool returning the same transaction multiple times (#6535)
API
---
### API
* Better handling of stable-only build (#6569)
* Remove the service builder (#6557)
@@ -302,8 +300,7 @@ API
## 2.0.0-rc3 -> 2.0.0-rc4 (Rhinoceros)
Runtime
-------
### Runtime
* Staking Payout Creates Controller (#6496)
* `pallet-scheduler`: Check that `when` is not in the past (#6480)
@@ -321,8 +318,7 @@ Runtime
* Add events for balance reserve and unreserve functions (#6330)
* Introduce frozen indices. (#6307)
Client
------
### Client
* client/network/service: Add primary dimension to connection metrics (#6472)
* Fix Babe secondary plain slots claiming (#6451)
@@ -340,8 +336,7 @@ Client
* new crate sc-light (#6235)
* Allow adding a prefix to the informant (#6174)
API
---
### API
* seal: Remove ext_dispatch_call and ext_get_runtime_storage (#6464)
* seal: Refactor ext_gas_price (#6478)
@@ -356,16 +351,14 @@ API
## 2.0.0-rc2 -> 2.0.0-rc3
Runtime
-------
### Runtime
* Introduce stacked filtering (#6273)
* Allow "pure" proxied accounts (#6236)
* Allow over-weight collective proposals to be closed (#6163)
* Fix Election when ForceNone V1 (#6166)
Client
------
### Client
* Make transaction pool prune transactions only of canonical blocks (#6123)
* Rename all the election operations (#6245)
@@ -381,14 +374,12 @@ Client
## 2.0.0-alpha.8 -> 2.0.0-rc1
Runtime
-------
### Runtime
* Allow operational recovery path if on_initialize use fullblock. (#6089)
* Maximum extrinsic weight limit (#6067)
Client
------
### Client
* Add JSON format to import blocks and set it as default (#5816)
* Upgrade to libp2p v0.19 - Changes the default PeerId representation (#6064)
@@ -396,17 +387,17 @@ Client
## 2.0.0-alpha.7 -> 2.0.0-alpha.8
**License Changed**
From this release forward, the code is released under a new – more relaxed – license scheme: Client (`sc-*`) is released under "GPL 3.0 or newer with the Classpath Exception", while primitives, FRAME, the pallets, utils and test-utils are released under "Apache 2.0". More details in the [Relax licensing scheme PR](https://github.com/paritytech/substrate/pull/5947).
**License Changed** From this release forward, the code is released under a new – more relaxed – license scheme: Client
(`sc-*`) is released under "GPL 3.0 or newer with the Classpath Exception", while primitives, FRAME, the pallets, utils
and test-utils are released under "Apache 2.0". More details in the [Relax licensing scheme
PR](https://github.com/paritytech/substrate/pull/5947).
Runtime
-------
### Runtime
* Democracy weight (#5828)
* Make `Digest` support `StorageAppend` (#5922)
Client
------
### Client
* Meter block import results via prometheus (#6025)
* Added RuntimePublic for ecdsa public key. (#6029)
@@ -418,8 +409,7 @@ Client
## 2.0.0-alpha.6 -> 2.0.0-alpha.7
Runtime
-------
### Runtime
* Use `storage::append` in the implementation of the storage types (#5889)
* pallet-sudo: Store `DispatchResult` in `Sudid` event (#5804)
@@ -431,8 +421,7 @@ Runtime
* Transaction versioning in the RuntimeVersion (#5582)
* emit TipClosed event on success tip payout (#5656)
Client
------
### Client
* Adds `export-state` subcommand (#5842)
* Drop ClientProvider (#5823)
@@ -454,8 +443,7 @@ Client
* Use a Kademlia instance per `ProtocolId`. (#5045)
* Report tasks metrics to Prometheus (#5619)
API
---
### API
* Child trie api changes BREAKING (#4857)
* Pass max-total to RewardRemainder on end_era (#5697)
@@ -463,8 +451,7 @@ API
## 2.0.0-alpha.5 -> 2.0.0-alpha.6
Runtime
-------
### Runtime
* Unsigned Validation best practices (#5563)
* Generate Unit Tests for Benchmarks (#5527)
@@ -473,8 +460,7 @@ Runtime
* Pass transaction source to validate_transaction (#5366)
* on_initialize return weight consumed and default cost to default DispatchInfo instead of zero (#5382)
Client
------
### Client
* Add new RPC method to get the chain type (#5576)
* Reuse wasmtime instances, the PR (#5567)
@@ -488,10 +474,10 @@ Client
* Make transactions and block announces use notifications substre… (#5360)
* Adds state_queryStorageAt (#5362)
* Offchain Phragmén BREAKING. (#4517)
* `sc_rpc::system::SystemInfo.impl_version` now returns the full version (2.0.0-alpha.2-b950f731c-x86_64-linux-gnu) instead of the short version (1.0.0) (#5271)
* `sc_rpc::system::SystemInfo.impl_version` now returns the full version (2.0.0-alpha.2-b950f731c-x86_64-linux-gnu)
instead of the short version (1.0.0) (#5271)
API
---
### API
* Unsigned Validation best practices (#5563)
* Split the Roles in three types (#5520)
@@ -501,16 +487,14 @@ API
## 2.0.0-alpha.4 -> 2.0.0-alpha.5
Runtime
-------
### Runtime
* pallet-evm: configurable gasometer config (#5320)
* Adds new event phase `Initialization` (#5302)
## 2.0.0-alpha.3 -> 2.0.0-alpha.4
Runtime
-------
### Runtime
* Move runtime upgrade to `frame-executive` (#5197)
* Split fees and tips between author and treasury independently (#5207)
@@ -520,22 +504,20 @@ Runtime
* Adds `vested_transfer` to Vesting pallet (#5029)
* Change extrinsic_count to extrinsic_index in pallet-utility (#5044)
Client
------
### Client
* client/finality-grandpa: Add Prometheus metrics to GossipValidator (#5237)
* removes use of sc_client::Client from node-transaction-factory (#5158)
* removes use of sc_client::Client from sc_network (#5147)
* Use CLI to configure max instances cache (#5177)
* client/service/src/builder.rs: Add build_info metric (#5192)
* Remove substrate-ui.parity.io from CORS whitelist (#5142)
* Remove `substrate-ui.parity.io` from CORS whitelist (#5142)
* removes use of sc_client::Client from sc-rpc (#5063)
* Use 128mb for db cache default (#5134)
* Drop db-cache default from 1gig to 32mb (#5128)
* Add more metrics to prometheus (#5034)
API
---
### API
* Produce block always on updated transaction pool state (#5227)
* Add `ext_terminate` (#5234)
substrate/docs/SECURITY.md
+26 -14
View File
@@ -1,11 +1,14 @@
<!-- markdown-link-check-disable -->
# Security Policy
Parity Technologies is committed to resolving security vulnerabilities in our software quickly and carefully. We take the necessary steps to minimize risk, provide timely information, and deliver vulnerability fixes and mitigations required to address security issues.
Parity Technologies is committed to resolving security vulnerabilities in our software quickly and carefully. We take
the necessary steps to minimize risk, provide timely information, and deliver vulnerability fixes and mitigations
required to address security issues.
## Reporting a Vulnerability
Security vulnerabilities in Parity software should be reported by email to security@parity.io. If you think your report might be eligible for the Parity Bug Bounty Program, your email should be send to bugbounty@parity.io.
Security vulnerabilities in Parity software should be reported by email to security@parity.io. If you think your report
might be eligible for the Parity Bug Bounty Program, your email should be send to bugbounty@parity.io.
Your report should include the following:
@@ -16,11 +19,16 @@ Your report should include the following:
- reproduction
- other details
Try to include as much information in your report as you can, including a description of the vulnerability, its potential impact, and steps for reproducing it. Be sure to use a descriptive subject line.
Try to include as much information in your report as you can, including a description of the vulnerability, its
potential impact, and steps for reproducing it. Be sure to use a descriptive subject line.
You'll receive a response to your email within two business days indicating the next steps in handling your report. We encourage finders to use encrypted communication channels to protect the confidentiality of vulnerability reports. You can encrypt your report using our public key. This key is [on MIT's key server](https://pgp.mit.edu/pks/lookup?op=get&search=0x5D0F03018D07DE73) server and reproduced below.
You'll receive a response to your email within two business days indicating the next steps in handling your report. We
encourage finders to use encrypted communication channels to protect the confidentiality of vulnerability reports. You
can encrypt your report using our public key. This key is [on MIT's key
server](https://pgp.mit.edu/pks/lookup?op=get&search=0x5D0F03018D07DE73) server and reproduced below.
After the initial reply to your report, our team will endeavor to keep you informed of the progress being made towards a fix. These updates will be sent at least every five business days.
After the initial reply to your report, our team will endeavor to keep you informed of the progress being made towards a
fix. These updates will be sent at least every five business days.
Thank you for taking the time to responsibly disclose any vulnerabilities you find.
@@ -29,19 +37,23 @@ Thank you for taking the time to responsibly disclose any vulnerabilities you fi
Responsible investigation and reporting includes, but isn't limited to, the following:
- Don't violate the privacy of other users, destroy data, etc.
- Don’t defraud or harm Parity Technologies Ltd or its users during your research; you should make a good faith effort to not interrupt or degrade our services.
- Don't target our physical security measures, or attempt to use social engineering, spam, distributed denial of service (DDOS) attacks, etc.
- Don’t defraud or harm Parity Technologies Ltd or its users during your research; you should make a good faith effort
to not interrupt or degrade our services.
- Don't target our physical security measures, or attempt to use social engineering, spam, distributed denial of service
(DDOS) attacks, etc.
- Initially report the bug only to us and not to anyone else.
- Give us a reasonable amount of time to fix the bug before disclosing it to anyone else, and give us adequate written warning before disclosing it to anyone else.
- In general, please investigate and report bugs in a way that makes a reasonable, good faith effort not to be disruptive or harmful to us or our users. Otherwise your actions might be interpreted as an attack rather than an effort to be helpful.
- Give us a reasonable amount of time to fix the bug before disclosing it to anyone else, and give us adequate written
warning before disclosing it to anyone else.
- In general, please investigate and report bugs in a way that makes a reasonable, good faith effort not to be
disruptive or harmful to us or our users. Otherwise your actions might be interpreted as an attack rather than an
effort to be helpful.
## Bug Bounty Program
Our Bug Bounty Program allows us to recognize and reward members of the Parity community for helping us find and address significant bugs, in accordance with the terms of the Parity Bug Bounty Program. A detailed description on eligibility, rewards, legal information and terms & conditions for contributors can be found on [our website](https://paritytech.io/bug-bounty.html).
Our Bug Bounty Program allows us to recognize and reward members of the Parity community for helping us find and address
significant bugs, in accordance with the terms of the Parity Bug Bounty Program. A detailed description on eligibility,
rewards, legal information and terms & conditions for contributors can be found on [our
website](https://paritytech.io/bug-bounty.html).
## Plaintext PGP Key
substrate/docs/STYLE_GUIDE.md
+35 -35
View File
@@ -2,19 +2,18 @@
title: Style Guide for Rust in Substrate
---
Where possible these styles are enforced by settings in `rustfmt.toml` so if you run `cargo fmt`
then you will adhere to most of these style guidelines automatically.
Where possible these styles are enforced by settings in `rustfmt.toml` so if you run `cargo fmt` then you will adhere to
most of these style guidelines automatically.
# Code Formatting
- Indent using tabs.
- Lines should be longer than 100 characters long only in exceptional circumstances and certainly
no longer than 120. For this purpose, tabs are considered 4 characters wide.
- Indent levels should be greater than 5 only in exceptional circumstances and certainly no
greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in
order to strip out complex inline expressions.
- Never have spaces on a line prior to a non-whitespace character
- Follow-on lines are only ever a single indent from the original line.
- Indent using tabs.
- Lines should be longer than 100 characters long only in exceptional circumstances and certainly no longer than 120.
For this purpose, tabs are considered 4 characters wide.
- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are
greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions.
- Never have spaces on a line prior to a non-whitespace character
- Follow-on lines are only ever a single indent from the original line.
```rust
fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool {
@@ -25,8 +24,8 @@ fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool {
}
```
- Indent level should follow open parens/brackets, but should be collapsed to the smallest number
of levels actually used:
- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually
used:
```rust
fn calculate(
@@ -45,10 +44,10 @@ fn calculate(
}
```
- `where` is indented, and its items are indented one further.
- Argument lists or function invocations that are too long to fit on one line are indented
similarly to code blocks, and once one param is indented in such a way, all others should be,
too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls.
- `where` is indented, and its items are indented one further.
- Argument lists or function invocations that are too long to fit on one line are indented similarly to code blocks, and
once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for
single-line run-ons of basic function calls.
```rust
// OK
@@ -92,7 +91,7 @@ fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_nam
}
```
- Always end last item of a multi-line comma-delimited set with `,` when legal:
- Always end last item of a multi-line comma-delimited set with `,` when legal:
```rust
struct Point<T> {
@@ -104,7 +103,7 @@ struct Point<T> {
enum Meal { Breakfast, Lunch, Dinner };
```
- Avoid trailing `;`s where unneeded.
- Avoid trailing `;`s where unneeded.
```rust
if condition {
@@ -112,8 +111,8 @@ if condition {
}
```
- `match` arms may be either blocks or have a trailing `,` but not both.
- Blocks should not be used unnecessarily.
- `match` arms may be either blocks or have a trailing `,` but not both.
- Blocks should not be used unnecessarily.
```rust
match meal {
@@ -126,9 +125,8 @@ match meal {
# Style
- Panickers require explicit proofs they don't trigger. Calling `unwrap` is discouraged. The
exception to this rule is test code. Avoiding panickers by restructuring code is preferred if
feasible.
- Panickers require explicit proofs they don't trigger. Calling `unwrap` is discouraged. The exception to this rule is
test code. Avoiding panickers by restructuring code is preferred if feasible.
```rust
let mut target_path =
@@ -139,21 +137,22 @@ let mut target_path =
);
```
- Unsafe code requires explicit proofs just as panickers do. When introducing unsafe code,
consider trade-offs between efficiency on one hand and reliability, maintenance costs, and
security on the other. Here is a list of questions that may help evaluating the trade-off while
preparing or reviewing a PR:
- how much more performant or compact the resulting code will be using unsafe code,
- how likely is it that invariants could be violated,
- are issues stemming from the use of unsafe code caught by existing tests/tooling,
- what are the consequences if the problems slip into production.
- Unsafe code requires explicit proofs just as panickers do. When introducing unsafe code, consider trade-offs between
efficiency on one hand and reliability, maintenance costs, and security on the other. Here is a list of questions
that may help evaluating the trade-off while preparing or reviewing a PR:
- how much more performant or compact the resulting code will be using unsafe code,
- how likely is it that invariants could be violated,
- are issues stemming from the use of unsafe code caught by existing tests/tooling,
- what are the consequences if the problems slip into production.
# Manifest Formatting
> **TLDR**
> You can use the CLI tool [Zepter](https://crates.io/crates/zepter) to format the files: `zepter format features`
> **TLDR** You can use the CLI tool [Zepter](https://crates.io/crates/zepter) to format the files: `zepter format
> features`
Rust `Cargo.toml` files need to respect certain formatting rules. All entries need to be alphabetically sorted. This makes it easier to read them and insert new entries. The exhaustive list of rules is enforced by the CI. The general format looks like this:
Rust `Cargo.toml` files need to respect certain formatting rules. All entries need to be alphabetically sorted. This
makes it easier to read them and insert new entries. The exhaustive list of rules is enforced by the CI. The general
format looks like this:
- The feature is written as a single line if it fits within 80 chars:
```toml
@@ -161,7 +160,8 @@ Rust `Cargo.toml` files need to respect certain formatting rules. All entries ne
default = [ "std" ]
```
- Otherwise the feature is broken down into multiple lines with one entry per line. Each line is padded with one tab and no trailing spaces but a trailing comma.
- Otherwise the feature is broken down into multiple lines with one entry per line. Each line is padded with one tab and
no trailing spaces but a trailing comma.
```toml
[features]
default = [
substrate/docs/Upgrade.md
+5 -3
View File
@@ -1,5 +1,7 @@
# Upgrade path for you building on substrate
# Upgrade path for you building on Substrate
## master
- crate rename has been fixed `sp-application-crypto` (was `sc-application-crypto`); `.maintain/rename-crates-for-2.0.sh` has been updated accordingly, you can use it to upgrade to latest naming convention
- crates have been renamed, run `bash .maintain/rename-crates-for-2.0.sh`
- crate rename has been fixed `sp-application-crypto` (was `sc-application-crypto`);
`.maintain/rename-crates-for-2.0.sh` has been updated accordingly, you can use it to upgrade to latest naming
convention
- crates have been renamed, run `bash .maintain/rename-crates-for-2.0.sh`
substrate/docs/Upgrading-2.0-to-3.0.md
+103 -37
View File
@@ -4,7 +4,8 @@ An incomplete guide.
## Refreshing the node-template
Not much has changed on the top and API level for developing Substrate between 2.0 and 3.0. If you've made only small changes to the node-template, we recommend to do the following - it is easiest and quickest path forward:
Not much has changed on the top and API level for developing Substrate between 2.0 and 3.0. If you've made only small
changes to the node-template, we recommend to do the following - it is easiest and quickest path forward:
1. take a diff between 2.0 and your changes
2. store that diff
3. remove everything, copy over the 3.0 node-template
@@ -12,19 +13,30 @@ Not much has changed on the top and API level for developing Substrate between 2
## In-Depth guide on the changes
If you've made significant changes or diverted from the node-template a lot, starting out with that is probably not helping. For that case, we'll take a look at all changes between 2.0 and 3.0 to the fully-implemented node and explain them one by one, so you can follow up, what needs to be changing for your node.
If you've made significant changes or diverted from the node-template a lot, starting out with that is probably not
helping. For that case, we'll take a look at all changes between 2.0 and 3.0 to the fully-implemented node and explain
them one by one, so you can follow up, what needs to be changing for your node.
_Note_: Of course, step 1 is to upgrade your `Cargo.toml`'s to use the latest version of Substrate and all dependencies.
We'll be taking the diff from 2.0.1 to 3.0.0 on `bin/node` as the baseline of what has changed between these two versions in terms of adapting ones code base. We will not be covering the changes made on the tests and bench-marking as they are mostly reactions to the other changes.
We'll be taking the diff from 2.0.1 to 3.0.0 on `bin/node` as the baseline of what has changed between these two
versions in terms of adapting ones code base. We will not be covering the changes made on the tests and bench-marking as
they are mostly reactions to the other changes.
### Versions upgrade
First and foremost you have to upgrade the version pf the dependencies of course, that's `0.8.x -> 0.9.0` and `2.0.x -> 3.0.0` for all `sc-`, `sp-`, `frame-`, and `pallet-` coming from Parity. Further more this release also upgraded its own dependencies, most notably, we are now using `parity-scale-codec 2.0`, `parking_lot 0.11` and `substrate-wasm-builder 3.0.0` (as build dependency). All other dependency upgrades should resolve automatically or are just internal. However you might see some error that another dependency/type you have as a dependency and one of our upgraded crates don't match up, if so please check the version of said dependency - we've probably upgraded it.
First and foremost you have to upgrade the version pf the dependencies of course, that's `0.8.x -> 0.9.0` and `2.0.x ->
3.0.0` for all `sc-`, `sp-`, `frame-`, and `pallet-` coming from Parity. Further more this release also upgraded its own
dependencies, most notably, we are now using `parity-scale-codec 2.0`, `parking_lot 0.11` and `substrate-wasm-builder
3.0.0` (as build dependency). All other dependency upgrades should resolve automatically or are just internal. However
you might see some error that another dependency/type you have as a dependency and one of our upgraded crates don't
match up, if so please check the version of said dependency - we've probably upgraded it.
### WASM-Builder
The new version of wasm-builder has gotten a bit smarter and a lot faster (you should definitely switch). Once you've upgraded the dependency, in most cases you just have to remove the now obsolete `with_wasm_builder_from_crates_or_path`-function and you are good to go:
The new version of wasm-builder has gotten a bit smarter and a lot faster (you should definitely switch). Once you've
upgraded the dependency, in most cases you just have to remove the now obsolete
`with_wasm_builder_from_crates_or_path`-function and you are good to go:
```diff: rust
--- a/bin/node/runtime/build.rs
@@ -49,11 +61,15 @@ The new version of wasm-builder has gotten a bit smarter and a lot faster (you s
#### FRAME 2.0
The new FRAME 2.0 macros are a lot nicer to use and easier to read. While we were on that change though, we also cleaned up some mainly internal names and traits. The old `macro`'s still work and also produce the new structure, however, when plugging all that together as a Runtime, there's some things we have to adapt now:
The new FRAME 2.0 macros are a lot nicer to use and easier to read. While we were on that change though, we also cleaned
up some mainly internal names and traits. The old `macro`'s still work and also produce the new structure, however, when
plugging all that together as a Runtime, there's some things we have to adapt now:
##### `::Trait for Runtime` becomes `::Config for Runtime`
The most visible and significant change is that the macros no longer generate the `$pallet::Trait` but now a much more aptly named `$pallet::Config`. Thus, we need to rename all `::Trait for Runtime` into`::Config for Runtime`, e.g. for the `sudo` pallet we must do:
The most visible and significant change is that the macros no longer generate the `$pallet::Trait` but now a much more
aptly named `$pallet::Config`. Thus, we need to rename all `::Trait for Runtime` into`::Config for Runtime`, e.g. for
the `sudo` pallet we must do:
```diff
-impl pallet_sudo::Trait for Runtime {
@@ -65,11 +81,15 @@ The same goes for all `<Self as frame_system::Trait>` and alike, which simply be
#### SS58 Prefix is now a runtime param
Since [#7810](https://github.com/paritytech/substrate/pull/7810) we don't define the ss58 prefix in the chainspec anymore but moved it into the runtime. Namely, `frame_system` now needs a new `SS58Prefix`, which in substrate node we have defined for ourselves as: `pub const SS58Prefix: u8 = 42;`. Use your own chain-specific value there.
Since [#7810](https://github.com/paritytech/substrate/pull/7810) we don't define the ss58 prefix in the chainspec
anymore but moved it into the runtime. Namely, `frame_system` now needs a new `SS58Prefix`, which in Substrate node we
have defined for ourselves as: `pub const SS58Prefix: u8 = 42;`. Use your own chain-specific value there.
#### Weight Definition
`type WeightInfo` has changed and instead on `weights::pallet_$name::WeightInfo` is now bound to the Runtime as `pallet_$name::weights::SubstrateWeight<Runtime>`. As a result we have to the change the type definitions everywhere in our Runtime accordingly:
`type WeightInfo` has changed and instead on `weights::pallet_$name::WeightInfo` is now bound to the Runtime as
`pallet_$name::weights::SubstrateWeight<Runtime>`. As a result we have to the change the type definitions everywhere in
our Runtime accordingly:
```diff
- type WeightInfo = weights::pallet_$name::WeightInfo;
@@ -170,24 +190,29 @@ And update the overall definition for weights on frame and a few related types a
+ type SystemWeightInfo = frame_system::weights::SubstrateWeight<Runtime>;
```
#### Pallets:
#### Pallets
##### Assets
The assets pallet has seen a variety of changes:
- [Features needed for reserve-backed stablecoins #7152 ](https://github.com/paritytech/substrate/pull/7152)
- [Freeze Assets and Asset Metadata #7346 ](https://github.com/paritytech/substrate/pull/7346)
- [Introduces account existence providers reference counting #7363 ]((https://github.com/paritytech/substrate/pull/7363))
- [Features needed for reserve-backed stablecoins #7152](https://github.com/paritytech/substrate/pull/7152)
- [Freeze Assets and Asset Metadata #7346](https://github.com/paritytech/substrate/pull/7346)
- [Introduces account existence providers reference counting #7363]((https://github.com/paritytech/substrate/pull/7363))
have all altered the feature set and changed the concepts. However, it has some of the best documentation and explains the current state very well. If you are using the assets pallet and need to upgrade from an earlier version, we recommend you use the current docs to guide your way!
have all altered the feature set and changed the concepts. However, it has some of the best documentation and explains
the current state very well. If you are using the assets pallet and need to upgrade from an earlier version, we
recommend you use the current docs to guide your way!
##### Contracts
As noted in the changelog, the `contracts`-pallet is still undergoing massive changes and is not yet part of this release. We are expecting for it to be released a few weeks after. If your chain is dependent on this pallet, we recommend to wait until it has been released as the currently released version is not compatible with FRAME 2.0.
As noted in the changelog, the `contracts`-pallet is still undergoing massive changes and is not yet part of this
release. We are expecting for it to be released a few weeks after. If your chain is dependent on this pallet, we
recommend to wait until it has been released as the currently released version is not compatible with FRAME 2.0.
#### (changes) Treasury
As mentioned above, Bounties, Tips and Lottery have been extracted out of treasury into their own pallets - removing these options here. Secondly we must now specify the `BurnDestination` and `SpendFunds`, which now go the `Bounties`.
As mentioned above, Bounties, Tips and Lottery have been extracted out of treasury into their own pallets - removing
these options here. Secondly we must now specify the `BurnDestination` and `SpendFunds`, which now go the `Bounties`.
```diff
- type Tippers = Elections;
@@ -206,9 +231,10 @@ As mentioned above, Bounties, Tips and Lottery have been extracted out of treasu
+ type SpendFunds = Bounties;
```
Factoring out Bounties and Tips means most of these definitions have now moved there, while the parameter types can be left as they were:
Factoring out Bounties and Tips means most of these definitions have now moved there, while the parameter types can be
left as they were:
###### 🆕 Bounties
##### 🆕 Bounties
```rust=
impl pallet_bounties::Config for Runtime {
@@ -241,11 +267,15 @@ impl pallet_tips::Config for Runtime {
#### `FinalityTracker` removed
Finality Tracker has been removed in favor of a different approach to handle the issue in GRANDPA, [see #7228 for details](https://github.com/paritytech/substrate/pull/7228). With latest GRANDPA this is not needed anymore and can be removed without worry.
Finality Tracker has been removed in favor of a different approach to handle the issue in GRANDPA, [see #7228 for
details](https://github.com/paritytech/substrate/pull/7228). With latest GRANDPA this is not needed anymore and can be
removed without worry.
#### (changes) Elections Phragmen
The pallet has been moved to a new system in which the exact amount of deposit for each voter, candidate, member, or runner-up is now deposited on-chain. Moreover, the concept of a `defunct_voter` is removed, since votes now have adequate deposit associated with them. A number of configuration parameters has changed to reflect this, as shown below:
The pallet has been moved to a new system in which the exact amount of deposit for each voter, candidate, member, or
runner-up is now deposited on-chain. Moreover, the concept of a `defunct_voter` is removed, since votes now have
adequate deposit associated with them. A number of configuration parameters has changed to reflect this, as shown below:
```diff=
parameter_types! {
@@ -277,11 +307,16 @@ The pallet has been moved to a new system in which the exact amount of deposit f
type TermDuration = TermDuration;
```
**This upgrade requires storage [migration](https://github.com/paritytech/substrate/blob/master/frame/elections-phragmen/src/migrations_3_0_0.rs)**. Further details can be found in the [pallet-specific changelog](https://github.com/paritytech/substrate/blob/master/frame/elections-phragmen/CHANGELOG.md#security).
**This upgrade requires storage
[migration](https://github.com/paritytech/substrate/blob/master/frame/elections-phragmen/src/migrations_3_0_0.rs)**.
Further details can be found in the [pallet-specific
changelog](https://github.com/paritytech/substrate/blob/master/frame/elections-phragmen/CHANGELOG.md#security).
#### (changes) Democracy
Democracy brings three new settings with this release, all to allow for better influx- and spam-control. Namely these allow to specify the maximum number of proposals at a time, who can blacklist and who can cancel proposals. This diff acts as a good starting point:
Democracy brings three new settings with this release, all to allow for better influx- and spam-control. Namely these
allow to specify the maximum number of proposals at a time, who can blacklist and who can cancel proposals. This diff
acts as a good starting point:
```diff=
@@ -508,6 +537,14 @@ impl pallet_democracy::Trait for Runtime {
@@ -311,7 +346,9 @@ Democracy brings three new settings with this release, all to allow for better i
### Primitives
The shared primitives define the API between Client and Runtime. Usually, you don't have to touch nor directly interact with them, unless you created your own client or frame-less runtime. Therefore we'd expect you to understand whether you are effected by changes and how to update your code yourself.
The shared primitives define the API between Client and Runtime. Usually, you don't have to touch nor directly interact
with them, unless you created your own client or frame-less runtime. Therefore we'd expect you to understand whether you
are effected by changes and how to update your code yourself.
----
@@ -321,10 +358,17 @@ The shared primitives define the API between Client and Runtime. Usually, you do
A few minor things have changed in the `cli` (compared to 2.0.1):
1. we've [replaced the newly added `BuildSyncSpec` subcommand with an RPC API](https://github.com/paritytech/substrate/commit/65cc9af9b8df8d36928f6144ee7474cefbd70454#diff-c57da6fbeff8c46ce15f55ea42fedaa5a4684d79578006ce4af01ae04fd6b8f8) in an on-going effort to make light-client-support smoother, see below
2. we've [removed double accounts from our chainspec-builder](https://github.com/paritytech/substrate/commit/31499cd29ed30df932fb71b7459796f7160d0272)
3. we [don't fallback to `--chain flaming-fir` anymore](https://github.com/paritytech/substrate/commit/13cdf1c8cd2ee62d411f82b64dc7eba860c9c6c6), if no chain is given our substrate-node will error.
4. [the `subkey`-integration has seen a fix to the `insert`-command](https://github.com/paritytech/substrate/commit/54bde60cfd2c544c54e9e8623b6b8725b99557f8) that requires you to now add the `&cli` as a param.
1. we've [replaced the newly added `BuildSyncSpec` subcommand with an RPC
API](https://github.com/paritytech/substrate/commit/65cc9af9b8df8d36928f6144ee7474cefbd70454#diff-c57da6fbeff8c46ce15f55ea42fedaa5a4684d79578006ce4af01ae04fd6b8f8)
in an on-going effort to make light-client-support smoother, see below
2. we've [removed double accounts from our
chainspec-builder](https://github.com/paritytech/substrate/commit/31499cd29ed30df932fb71b7459796f7160d0272)
3. we [don't fallback to `--chain flaming-fir`
anymore](https://github.com/paritytech/substrate/commit/13cdf1c8cd2ee62d411f82b64dc7eba860c9c6c6), if no chain is
given our `substrate-node` will error.
4. [the `subkey`-integration has seen a fix to the
`insert`-command](https://github.com/paritytech/substrate/commit/54bde60cfd2c544c54e9e8623b6b8725b99557f8) that
requires you to now add the `&cli` as a param.
```diff=
--- a/bin/node/cli/src/command.rs
+++ b/bin/node/cli/src/command.rs
@@ -344,7 +388,8 @@ A few minor things have changed in the `cli` (compared to 2.0.1):
##### Light client support
As said, we've added a new optional RPC service for improved light client support. For that to work, we need to pass the `chain_spec` and give access to the `AuxStore` to our `rpc`:
As said, we've added a new optional RPC service for improved light client support. For that to work, we need to pass the
`chain_spec` and give access to the `AuxStore` to our `rpc`:
```diff=
@@ -438,17 +483,30 @@ and add the new service:
##### Telemetry
The telemetry subsystem has seen a few fixes and refactorings to allow for a more flexible handling, in particular in regards to parachains. Most notably `sc_service::spawn_tasks` now returns the `telemetry_connection_notifier` as the second member of the tuple, (`let (_rpc_handlers, telemetry_connection_notifier) = sc_service::spawn_tasks(`), which should be passed to `telemetry_on_connect` of `new_full_base` now: `telemetry_on_connect: telemetry_connection_notifier.map(|x| x.on_connect_stream()),` (see the service-section below for a full diff).
The telemetry subsystem has seen a few fixes and refactorings to allow for a more flexible handling, in particular in
regards to parachains. Most notably `sc_service::spawn_tasks` now returns the `telemetry_connection_notifier` as the
second member of the tuple, (`let (_rpc_handlers, telemetry_connection_notifier) = sc_service::spawn_tasks(`), which
should be passed to `telemetry_on_connect` of `new_full_base` now: `telemetry_on_connect:
telemetry_connection_notifier.map(|x| x.on_connect_stream()),` (see the service-section below for a full diff).
##### Async & Remote Keystore support
In order to allow for remote-keystores, the keystore-subsystem has been reworked to support async operations and generally refactored to not provide the keys itself but only sign on request. This allows for remote-keystore to never hand out keys and thus to operate any substrate-based node in a manner without ever having the private keys in the local system memory.
In order to allow for remote-keystores, the keystore-subsystem has been reworked to support async operations and
generally refactored to not provide the keys itself but only sign on request. This allows for remote-keystore to never
hand out keys and thus to operate any Substrate-based node in a manner without ever having the private keys in the local
system memory.
There are some operations, however, that the keystore must be local for performance reasons and for which a remote keystore won't work (in particular around parachains). As such, the keystore has both a slot for remote but also always a local instance, where some operations hard bind to the local variant, while most subsystems just ask the generic keystore which prefers a remote signer if given. To reflect this change, `sc_service::new_full_parts` now returns a `KeystoreContainer` rather than the keystore, and the other subsystems (e.g. `sc_service::PartialComponents`) expect to be given that.
There are some operations, however, that the keystore must be local for performance reasons and for which a remote
keystore won't work (in particular around parachains). As such, the keystore has both a slot for remote but also always
a local instance, where some operations hard bind to the local variant, while most subsystems just ask the generic
keystore which prefers a remote signer if given. To reflect this change, `sc_service::new_full_parts` now returns a
`KeystoreContainer` rather than the keystore, and the other subsystems (e.g. `sc_service::PartialComponents`) expect to
be given that.
###### on RPC:
###### on RPC
This has most visible changes for the rpc, where we are switching from the previous `KeyStorePtr` to the new `SyncCryptoStorePtr`:
This has most visible changes for the rpc, where we are switching from the previous `KeyStorePtr` to the new
`SyncCryptoStorePtr`:
```diff
@@ -483,9 +541,15 @@ This has most visible changes for the rpc, where we are switching from the previ
##### GRANDPA
As already in the changelog, a few things significant things have changed in regards to GRANDPA: the finality tracker has been replaced, an RPC command has been added and WARP-sync-support for faster light client startup has been implemented. All this means we have to do a few changes to our GRANDPA setup procedures in the client.
As already in the changelog, a few things significant things have changed in regards to GRANDPA: the finality tracker
has been replaced, an RPC command has been added and WARP-sync-support for faster light client startup has been
implemented. All this means we have to do a few changes to our GRANDPA setup procedures in the client.
First and foremost, grandpa internalised a few aspects, and thus `new_partial` doesn't expect a tuple but only the `grandpa::SharedVoterState` as input now, and unpacking that again later is not needed anymore either. On the opposite side `grandpa::FinalityProofProvider::new_for_service` now requires the `Some(shared_authority_set)` to be passed as a new third parameter. This set also becomes relevant when adding warp-sync-support, which is added as an extra-protocol-layer to the networking as:
First and foremost, grandpa internalised a few aspects, and thus `new_partial` doesn't expect a tuple but only the
`grandpa::SharedVoterState` as input now, and unpacking that again later is not needed anymore either. On the opposite
side `grandpa::FinalityProofProvider::new_for_service` now requires the `Some(shared_authority_set)` to be passed as a
new third parameter. This set also becomes relevant when adding warp-sync-support, which is added as an
extra-protocol-layer to the networking as:
```diff=
+ config.network.extra_sets.push(grandpa::grandpa_peers_set_config());
@@ -496,11 +560,13 @@ First and foremost, grandpa internalised a few aspects, and thus `new_partial` d
+ ));
```
As these changes pull through the entirety of `cli/src/service.rs`, we recommend looking at the final diff below for guidance.
As these changes pull through the entirety of `cli/src/service.rs`, we recommend looking at the final diff below for
guidance.
##### In a nutshell
Altogether this accumulates to the following diff for `node/cli/src/service.rs`. If you want these features and have modified your chain you should probably try to apply these patches:
Altogether this accumulates to the following diff for `node/cli/src/service.rs`. If you want these features and have
modified your chain you should probably try to apply these patches:
```diff=
substrate/docs/node-template-release.md
+45 -51
View File
@@ -1,71 +1,65 @@
# Substrate Node Template Release Process
1. This release process has to be run in a github checkout Substrate directory with your work
committed into `https://github.com/paritytech/substrate/`, because the build script will check
the existence of your current git commit ID in the remote repository.
## This release process has to be run in a github checkout Substrate directory with your work committed into
`https://github.com/paritytech/substrate/`, because the build script will check the existence of your current git commit
ID in the remote repository.
Assume you are in root directory of Substrate. Run:
Assume you are in root directory of Substrate. Run:
```bash
cd scripts/ci/
./node-template-release.sh <output tar.gz file>
```
```bash
cd scripts/ci/ ./node-template-release.sh <output tar.gz file>
```
2. Expand the output tar gzipped file and replace files in current Substrate Node Template
by running the following command.
## Expand the output tar gzipped file and replace files in current Substrate Node Template by running the following
command.
```bash
# This is where the tar.gz file uncompressed
cd substrate-node-template
# rsync with force copying. Note the slash at the destination directory is important
rsync -avh * <destination node-template directory>/
# For dry-running add `-n` argument
# rsync -avhn * <destination node-template directory>/
```
```bash
# This is where the tar.gz file uncompressed cd substrate-node-template # rsync with force copying. Note the
slash at the destination directory is important rsync -avh * <destination node-template directory>/ # For dry-running
add `-n` argument # rsync -avhn * <destination node-template directory>/
```
The above command only copies existing files from the source to the destination, but does not
delete files/directories that are removed from the source. So you need to manually check and
remove them in the destination.
The above command only copies existing files from the source to the destination, but does not delete files/directories
that are removed from the source. So you need to manually check and remove them in the destination.
3. There is a `Cargo.toml` file in the root directory. Inside, dependencies are listed form and
linked to a certain git commit in Substrate remote repository, such as:
## There is a `Cargo.toml` file in the root directory. Inside, dependencies are listed form and linked to a certain git
commit in Substrate remote repository, such as:
```toml
sp-core = { version = "7.0.0", git = "https://github.com/paritytech/substrate.git", rev = "de80d0107336a9c7a2efdc0199015e4d67fcbdb5", default-features = false }
```
```toml
toml sp-core = { version = "7.0.0", git = "https://github.com/paritytech/substrate.git", rev =
"de80d0107336a9c7a2efdc0199015e4d67fcbdb5", default-features = false }
```
We will update each of them to link to the Rust [crate registry](https://crates.io/).
After confirming the versioned package is published in the crate, the above will become:
e will update each of them to link to the Rust [crate registry](https://crates.io/). After confirming the versioned
package is published in the crate, the above will become:
```toml
[workspace.dependencies]
sp-core = { version = "7.0.0", default-features = false }
```
```toml
[workspace.dependencies] sp-core = { version = "7.0.0", default-features = false }
```
P.S: This step can be automated if we update `node-template-release` package in
`scripts/ci/node-template-release`.
P.S: This step can be automated if we update `node-template-release` package in `scripts/ci/node-template-release`.
4. Once the `Cargo.toml` is updated, compile and confirm that the Node Template builds. Then commit
the changes to a new branch in [Substrate Node Template](https://github.com/substrate-developer-hub/substrate-node-template), and make a PR.
## Once the `Cargo.toml` is updated, compile and confirm that the Node Template builds. Then commit the changes to a new
branch in [Substrate Node Template](https://github.com/substrate-developer-hub/substrate-node-template), and make a PR.
> Note that there is a chance the code in Substrate Node Template works with the linked Substrate git
commit but not with published packages due to the latest (as yet) unpublished features. In this case,
rollback that section of the Node Template to its previous version to ensure the Node Template builds.
> Note that there is a chance the code in Substrate Node Template works with the linked Substrate git commit but not
with published packages due to the latest (as yet) unpublished features. In this case, rollback that section of the
Node Template to its previous version to ensure the Node Template builds.
5. Once the PR is merged, tag the merged commit in master branch with the version number
`vX.Y.Z+A` (e.g. `v3.0.0+1`). The `X`(major), `Y`(minor), and `Z`(patch) version number should
follow Substrate release version. The last digit is any significant fixes made in the Substrate
Node Template apart from Substrate. When the Substrate version is updated, this digit is reset to 0.
## Once the PR is merged, tag the merged commit in master branch with the version number `vX.Y.Z+A` (e.g. `v3.0.0+1`)
The `X`(major), `Y`(minor), and `Z`(patch) version number should follow Substrate release version. The last digit is any
significant fixes made in the Substrate Node Template apart from Substrate. When the Substrate version is updated, this
digit is reset to 0.
## Troubleshooting
- Running the script `./node-template-release.sh <output tar.gz file>`, after all tests passed
successfully, seeing the following error message:
- Running the script `./node-template-release.sh <output tar.gz file>`, after all tests passed successfully, seeing the
following error message:
```
thread 'main' panicked at 'Creates output file: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:250:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
```
thread 'main' panicked at 'Creates output file: Os { code: 2, kind: NotFound, message: "No such file or directory"
}', src/main.rs:250:10 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
This is likely due to that your output path is not a valid `tar.gz` filename or you don't have write
permission to the destination. Try with a simple output path such as `~/node-tpl.tar.gz`.
This is likely due to that your output path is not a valid `tar.gz` filename or you don't have write permission to the
destination. Try with a simple output path such as `~/node-tpl.tar.gz`.