-
Notifications
You must be signed in to change notification settings - Fork 95
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
Comments
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.
No it is not the same, but it could be integrated if wanted and someone does it ;) |
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 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? |
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 oflibp2p
arePeerId
s andMultiaddr
. Both of them depend on theMultihash
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 therust-libp2p
ecosystem.I have two questions:
parity-scale-codec
has anencode_as
attribute. Is this equivalent toserde(with)
? Would it be acceptable to removeparity-scale-codec
as a dependency frommultihash
and move theMultihash
implementation to an adapter crate where users then have to use theencode_as
feature of the derive?Thanks in advance! :)
The text was updated successfully, but these errors were encountered: