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

A question on semver stability #405

Open
thomaseizinger opened this issue Jan 31, 2023 · 2 comments
Open

A question on semver stability #405

thomaseizinger opened this issue Jan 31, 2023 · 2 comments

Comments

@thomaseizinger
Copy link

thomaseizinger commented Jan 31, 2023

Hi folks!

I am currently on a mission to reduce the number of breaking changes across the rust-libp2p ecosystem. One of the fundamental dependencies of libp2p are PeerIds and Multiaddr. Both of them depend on the Multihash type defined here: https://github.com/multiformats/rust-multihash.

That type comes with the scale-codec feature which brings this crate into its dependency tree.

You might see where this is going. With parity-scale-codec in our public API, any breaking change in this crate triggers a breaking change in pretty much every crate across the rust-libp2p ecosystem.

I have two questions:

  • Do you have a policy on semver stability? For example, at most 1 breaking change every 2 years etc.
  • I see that the custom-derive for parity-scale-codec has an encode_as attribute. Is this equivalent to serde(with)? Would it be acceptable to remove parity-scale-codec as a dependency from multihash and move the Multihash implementation to an adapter crate where users then have to use the encode_as feature of the derive?

Thanks in advance! :)

@bkchr
Copy link
Member

bkchr commented Feb 2, 2023

Do you have a policy on semver stability? For example, at most 1 breaking change every 2 years etc.

No we don't really have such a policy, but we try to keep the number of breaking changes small. The last year's where also relative "calm" when it comes to breaking releases of scale codec.

I see that the custom-derive for parity-scale-codec has an encode_as attribute. Is this equivalent to serde(with)? Would it be acceptable to remove parity-scale-codec as a dependency from multihash and move the Multihash implementation to an adapter crate where users then have to use the encode_as feature of the derive?

No it is not the same, but it could be integrated if wanted and someone does it ;)

@thomaseizinger
Copy link
Author

Do you have a policy on semver stability? For example, at most 1 breaking change every 2 years etc.

No we don't really have such a policy, but we try to keep the number of breaking changes small. The last year's where also relative "calm" when it comes to breaking releases of scale codec.

That is great news! Nevertheless, I'd prefer if we can find a solution that allows us to not have the dependency in the first place (see below).

I see that the custom-derive for parity-scale-codec has an encode_as attribute. Is this equivalent to serde(with)? Would it be acceptable to remove parity-scale-codec as a dependency from multihash and move the Multihash implementation to an adapter crate where users then have to use the encode_as feature of the derive?

No it is not the same, but it could be integrated if wanted and someone does it ;)

I am happy to contribute such a feature, perhaps in a minimal form to cover this usecase?

Do you know users of this feature in multihash and whether they'd be happy with this alternative?

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

2 participants