-
Notifications
You must be signed in to change notification settings - Fork 59
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
Tracking issue: Polish and stabilize the API #267
Comments
The reason why it is named
Does this matter much? It sounds to me like a breaking change because we can and not because it's needed. But I don't have a strong opinion, so I'm OK with changing.
This seems to be a feature that is actually used, it's contributed by a third part. I've also spotted (indirect) use at https://github.com/ipfs-shipyard/space/pull/15/files#diff-2a805ce01866e6037c0644ed5bb5eb49d4ef87fef1b576f258838ae7c45817a3R12.
The reason it's named Please make sure you get buy-in from the folks from Forest and Iroh (those are the biggest users that came to my mind), so that we don't end up in a situation where we've forks of multihash again. |
I think regular
Doesn't matter much. We should be able to do it backwards-compatible, i.e. with a deprecation warning first.
I wonder if there is a way for us provide this without it having to be in the library. Does
Didn't see that. Might be worth splitting so folks don't end up with both if they only need one.
Definitely. The goal of this is to make it better for everyone! |
Turns out this is already sorted because the |
Opened an issue here: paritytech/parity-scale-codec#405 |
I think for now, we can keep the dependency. We can revisit the idea of removing it once they released another major version. Until then, removing the feature now is just unnecessary friction. |
The discussion for how we can stabilize the API of this crate takes place here: #259.
This issue is here to track our progress and link to relevant tasks.
Tasks:
multihash
,multihash-codetable
andmultihash-derive
#266Error
an opaque typeMultihash
asMultihash
instead ofMultihashGeneric
MultihashDigest
: Derives are conventionally named after the trait they implementserde-codec
feature to serde: Use package renames insteadparity-scale-codec
dependency? Has a large API surface and is already on major version 3. Doesn't seem to be trust-worthy to not break our API in the future again.write_multihash
andread_multihash
from the public API: They are already exposed viaMultihash::read
andMultihash::write
arb
feature toquickcheck
: More conventionalThe above list are suggestions. Happy to debate all of them. The thinking was:
Overall, my suggestion would be to pack all of these into one breaking change which will hopefully be the last one for a long time.
The text was updated successfully, but these errors were encountered: