3.1.0 Release tracker

[akhilles]

Pending tasks:

• Review the docs.
• Consider cutting a release candidate (e.g. 3.1.0-rc-0).
• Test upgrade some of the dependents.
• Add a CHANGELOG
• Resolve Switching to slice16 by default increases already large resource footprint by 16x #93 (blocker)

[mjgarton]

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]

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]

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]

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

[akhilles]

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]

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

[yotarok]

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]

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

[akhilles]

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]

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]

Just released 3.1.0. Thanks for your patience! Created #113 to resolve the default impl selection. Then, we can release 3.2.0. Will go ahead and close this issue.

[akhilles]

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: #115. It's using the same strategy as the Rust std lib for custom allocators (see Box<T, A = Global>).

[KillingSpark]

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