search

mrhooray / crc-rs

Rust implementation of CRC(16, 32, 64) with support of various standards
Apache License 2.0
187 stars 49 forks source link

3.1.0 Release tracker #92

Open akhilles opened 1 year ago

akhilles commented 1 year ago

Pending tasks:

mjgarton commented 1 year ago

I noticed it's been a while since the last release and there are some useful features waiting. Is there anything I can do to help things along?

akhilles commented 1 year ago

The main thing that's still needed is a changelog, which shouldn't take long. I'll probably push out a release this week.

KillingSpark commented 1 year ago

Just as an idea from another project I contributed to: They offload the changelogs to the pull-request makers. They require an changelog entry with all merge requests that add features

If you need help with the changelog for the slice-16 stuff I'd be happy to help

KillingSpark commented 10 months ago

Any progress? I'd really love to see this release to get the performance improvements out there

akhilles commented 10 months ago

Sorry for taking so long, but I published 3.1.0-beta.1. I want to make sure there are no breaking changes before publishing 3.1.0. Will test upgrade some dependents.

KillingSpark commented 7 months ago

Fwiw I tried compiling the webrtc crate with the 3.1.0-beta.1 which worked great. Did you find any blockers?

yotarok commented 7 months ago

I am one who is eagerly waiting for the stabilization of Slice16 feature. I have also checked that 3.1.0-beta.1 works flawlessly in my project with both Bytewise and Slice16 tables.

KillingSpark commented 6 months ago

@akhilles is there anything I can do to help this move forward?

akhilles commented 6 months ago

Sorry again for not responding earlier! I did test 3.1.0-beta.1 against some popular crates and didn't find any issues. I think we're ok to releasing on that front.

My only remaining hesitancy in releasing 3.1.0 is how the feature flags will work with future SIMD implementations. It doesn't seem like a great fit, and it's hard to intuit the priorities of the various flags. I really hate to bikeshed this again, but I've been considering whether --cfg rustc flags would be more appropriate. Seems like others have considered this as well: https://www.reddit.com/r/rust/comments/sgegah/comment/huwzifj/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button.

Once the feature flags are published, they have to be supported indefinitely, which is why I want to make sure they're the right API.

In order to not delay the release further, wdyt about releasing 3.1.0 with the feature flags disabled just for now? People can still use Slice16 and NoTable. Once the feature flags vs --cfg rustc flags issue is resolved, we can release 3.2.0 with that change.

KillingSpark commented 6 months ago

I see the concern and I agree the SIMD implementations don't clearly fall into an order like the current implementations.

Even though it means that crates that do not update their code will not immediately profit of the optimizations I would be fine with releasing this without the feature flags

akhilles commented 6 months ago

Just released 3.1.0. Thanks for your patience! Created https://github.com/mrhooray/crc-rs/issues/113 to resolve the default impl selection. Then, we can release 3.2.0. Will go ahead and close this issue.

akhilles commented 6 months ago

Re-opening as I yanked 3.1.0 due to a breaking change. I have a working POC of a slightly different API that shouldn't break semver: https://github.com/mrhooray/crc-rs/pull/115. It's using the same strategy as the Rust std lib for custom allocators (see Box<T, A = Global>).

KillingSpark commented 6 months ago

115 looks like it would allow for relatively seamless integration of SIMD implementations. That's pretty cool!