paritytech/parity-scale-codec

A question on semver stability

thomaseizinger opened this issue · 2 comments

thomaseizinger commented

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 commented

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 commented

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?