Latest master commits not on crates.io

[zachmse]

Hello and thank you for the hard work you have put into this crate!

I noticed that the latest commits to the master branch are 8 months old and have not yet been released on crates.io. The new_custom() method has been added to the various digests since the last release, and I think it would be useful to have this method available via downloads from crates.io.

Would it be possible to create a new release? I would be more than happy to help out in anyway possible if there are outstanding issues that need to be resolved first.

On a related note, would you be okay with me opening a pull request to address clippy lint warnings? The changes necessary to resolve the warnings are very minimal and shouldn't require much effort to review.

[mrhooray]

Thanks for the note. I'm looking into getting #42 merged. Please feel free to help review or open PR for the warnings. Look forward to making a release afterwards.

[jacobrosenthal]

Excited to release a crate using new_custom and am also eagerly awaiting a release. Thanks for the excellent crate.

[mrhooray]

#42 landed in a state that requires major version bump and some v2 API changes are still in discussion. Released the commit before as v1.9.0 which includes some new APIs. Sorry for the delay and hope it's still useful.

[jacobrosenthal]

Sorry to see 1.9 yanked but obviously understand. Any chance of a 1.8.2 with new_custom?

[mrhooray]

Unfortunately the change that adds new_custom contains a breaking change on update func. Maybe your use case could pin to git & sha instead of cargo release?

[akhilles]

@mrhooray, is it worth pushing the new_custom and #42 changes as 2.0.0?

The v2 API being discussed in #48 will probably take quite a bit of time to materialize. Also, I think it's better to wait for const generics and const fns to land in stable Rust before considering significant API changes.

[akhilles]

Or let's identify a subset of the v2 API changes that can easily be implemented (such as using core::hash::Hasher trait, separating Algorithm and Crc).

A generics-based API can be pushed to v3.

[mrhooray]

Or let's identify a subset of the v2 API changes that can easily be implemented (such as using core::hash::Hasher trait, separating Algorithm and Crc).

Great idea to enable full customization sooner.

A generics-based API can be pushed to v3.

Is that mainly due to const fn/generics considerations? If so, would you consider developing Algorithm and Crc based API with generics first, and then add support for it when required language features stablize?

[akhilles]

If so, would you consider developing Algorithm and Crc based API with generics first, and then add support for it when required language features stabilize?

That could work. I'll open a [WIP] PR in a couple days.