paritytech / polkadot-sdk

The Parity Polkadot Blockchain SDK
https://polkadot.network/
1.63k stars 570 forks source link

Ability to maintain multiple crates with the same/synchronized version #4626

Open bkontur opened 1 month ago

bkontur commented 1 month ago

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:

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.

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 version X.Y.Z, so how to make sure, that staging-chain-spec-builder has/uses the exact same version.

bkontur commented 1 month ago

cc: @kianenigma @liamaharon @ggwpez @Morganamilo @EgorPopelyaev @michalkucharczyk

bkontur commented 1 month ago

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
bkchr commented 1 month ago

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.

michalkucharczyk commented 1 month ago

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?