Skip to content
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

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

Open
bkontur opened this issue May 29, 2024 · 4 comments
Open

Comments

@bkontur
Copy link
Contributor

bkontur commented May 29, 2024

Based on discussion: #4518 (comment)
Relates to: #4518

Current status

#4518 (comment)

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
Copy link
Contributor Author

bkontur commented May 29, 2024

@bkontur
Copy link
Contributor Author

bkontur commented May 29, 2024

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
Copy link
Member

bkchr commented May 29, 2024

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
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants