Open bkontur opened 1 month ago
cc: @kianenigma @liamaharon @ggwpez @Morganamilo @EgorPopelyaev @michalkucharczyk
Let's say we have sp-genesis-builder
and staging-chain-spec-builder
in the same version:
sp-genesis-builder::X.Y.Z
staging-chain-spec-builder::X.Y.Z
What if we need to patch just staging-chain-spec-builder
? What version do we need to change?
sp-genesis-builder::X.Y.Z
staging-chain-spec-builder::X.Y.Z+1
or
sp-genesis-builder::X.Y.Z+1
staging-chain-spec-builder::X.Y.Z+1
Cargo unifies crates across the same major version. So, whatever X.Y
you have and how you bump them, cargo should be able to pull the latest version of it into your project.
The other approach, alternative to tight version coupling In case of sp-genesis-builder
and staging-chain-spec-builder
:
gensis-builder
is a runtime API so theoretically every API change shall be done in new runtime API version.
And the chain-spec-builder
could check (during execution) if runtime is compatible with builder implementation.
That would require keeping backward compatibility with all runtime versions which maybe inconvenient.
Not sure however which approach is better. What you propose also seems reasonable - however it may not be possible to keep chain-spec-builder version synced with genesis-builder - e.g. imagine internal refactor of this tool which would require major/minor bump?
Based on discussion: https://github.com/paritytech/polkadot-sdk/pull/4518#issuecomment-2136441174 Relates to: https://github.com/paritytech/polkadot-sdk/pull/4518
Current status
https://github.com/paritytech/polkadot-sdk/pull/4518#issuecomment-2134731355
The end goal:
In other words, how to maintain or synchronize one crate's
[package.version]
with another crate's[package.version]
regardless of the release branch or master.E.g. the
sp-genesis-builder
has some versionX.Y.Z
, so how to make sure, thatstaging-chain-spec-builder
has/uses the exact same version.