docs: update developing #1769
docs: update developing #1769
Conversation
| @@ -84,33 +84,28 @@ You can play with it from the parachain client, make transfers, inspect events, | |||
| ## Linting | |||
|
|
|||
| ### Source code | |||
| Lint the source code with `cargo +nightly fmt`. This excludes certain paths (defined in `rustfmt.toml`) that we want to stay as close as possible to `paritytech/substrate` to simplify upgrading to new releases. | |||
| Lint the source code with `cargo fmt --all`. This excludes certain paths (defined in `rustfmt.toml`) that we want to stay as close as possible to `paritytech/substrate` to simplify upgrading to new releases. | |||
There was a problem hiding this comment.
Shouldn't this be the same command that we use in our CI - cargo fmt -- --check?
There was a problem hiding this comment.
Good point, I actually believe we should instead change the CI to check with --all 😅. IMO fmt --all here has no downsides as it is a superset of fmt. I also have to admit that I am not sure whether there is a difference between cargo fmt and cargo fmt --all for our workspace.
| diener update --polkadot --branch release-v$POLKADOT_NEW_VERSION; | ||
| diener update --substrate --branch polkadot-v$POLKADOT_NEW_VERSION; | ||
| diener update --cumulus --branch polkadot-v$POLKADOT_NEW_VERSION; | ||
| diener update --polkadot-sdk --branch release-v$POLKADOT_NEW_VERSION; |
There was a problem hiding this comment.
Just notify this behavior has not been merged yet: paritytech/diener#45. I hope we have it when we need it. Although since we use workspace dependencies, this is no longer an "issue" for us.
There was a problem hiding this comment.
Are you fine with keeping as proposed and iterating over this as part of the Polkadot SDK updates after v1.1.0?
There was a problem hiding this comment.
Yeah! Sure, I was only notifying
Description
Updates the developer docs by removing some deprecated bits. All lines were tested locally. Used as base for outstanding How to contribute docs in docs repository.
Checklist: