-
Notifications
You must be signed in to change notification settings - Fork 700
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
release chain-spec-builder #4352
Comments
CC @Morganamilo |
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/1 |
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/5 |
A small step towards https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823 and #4352. Many parachains use `camelCase` and/or `PascalCase`ing for their chain spec extension. Sometimes the only reason polkadot-parachain cannot sync them is because it cannot parse the chain spec extension. This PR relaxes the requirement for the extension to be camel case. --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
marking it as release-able, attaching the same version number that is attached to other binaries such as `polkadot` and `polkadot-parachain`. I have more thoughts about the version number, though. The chain-spec builder is mainly a user of the `sp-genesis-builder` api. So the versioning should be such that it helps users know give a version of `sp-genesis-builder` in their runtime, which version of `chain-spec-builder` should they use? With this, we can possibly alter the version number to always match `sp-genesis-builder`. Fixes #4352 - [x] Add to release artifacts ~~similar to #4405 done here: #4557 --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
marking it as release-able, attaching the same version number that is attached to other binaries such as `polkadot` and `polkadot-parachain`. I have more thoughts about the version number, though. The chain-spec builder is mainly a user of the `sp-genesis-builder` api. So the versioning should be such that it helps users know give a version of `sp-genesis-builder` in their runtime, which version of `chain-spec-builder` should they use? With this, we can possibly alter the version number to always match `sp-genesis-builder`. Fixes #4352 - [x] Add to release artifacts ~~similar to #4405 done here: #4557 --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
marking it as release-able, attaching the same version number that is attached to other binaries such as `polkadot` and `polkadot-parachain`. I have more thoughts about the version number, though. The chain-spec builder is mainly a user of the `sp-genesis-builder` api. So the versioning should be such that it helps users know give a version of `sp-genesis-builder` in their runtime, which version of `chain-spec-builder` should they use? With this, we can possibly alter the version number to always match `sp-genesis-builder`. Fixes #4352 - [x] Add to release artifacts ~~similar to #4405 done here: #4557 --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
@xlc you can now
|
Nice, thank you @bkontur @EgorPopelyaev! |
…#4452) A small step towards https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823 and paritytech#4352. Many parachains use `camelCase` and/or `PascalCase`ing for their chain spec extension. Sometimes the only reason polkadot-parachain cannot sync them is because it cannot parse the chain spec extension. This PR relaxes the requirement for the extension to be camel case. --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
marking it as release-able, attaching the same version number that is attached to other binaries such as `polkadot` and `polkadot-parachain`. I have more thoughts about the version number, though. The chain-spec builder is mainly a user of the `sp-genesis-builder` api. So the versioning should be such that it helps users know give a version of `sp-genesis-builder` in their runtime, which version of `chain-spec-builder` should they use? With this, we can possibly alter the version number to always match `sp-genesis-builder`. Fixes paritytech#4352 - [x] Add to release artifacts ~~similar to paritytech#4405 done here: paritytech#4557 --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
…#4452) A small step towards https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823 and paritytech#4352. Many parachains use `camelCase` and/or `PascalCase`ing for their chain spec extension. Sometimes the only reason polkadot-parachain cannot sync them is because it cannot parse the chain spec extension. This PR relaxes the requirement for the extension to be camel case. --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
…#4452) A small step towards https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823 and paritytech#4352. Many parachains use `camelCase` and/or `PascalCase`ing for their chain spec extension. Sometimes the only reason polkadot-parachain cannot sync them is because it cannot parse the chain spec extension. This PR relaxes the requirement for the extension to be camel case. --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
marking it as release-able, attaching the same version number that is attached to other binaries such as `polkadot` and `polkadot-parachain`. I have more thoughts about the version number, though. The chain-spec builder is mainly a user of the `sp-genesis-builder` api. So the versioning should be such that it helps users know give a version of `sp-genesis-builder` in their runtime, which version of `chain-spec-builder` should they use? With this, we can possibly alter the version number to always match `sp-genesis-builder`. Fixes paritytech#4352 - [x] Add to release artifacts ~~similar to paritytech#4405 done here: paritytech#4557 --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
so I can cargo install it and use it
The text was updated successfully, but these errors were encountered: