v0.6 release tracking ticket

[tarcieri]

This is a list of release blockers for crypto-bigint v0.6.0, nearly all of which are final releases of dependencies which are currently in a prerelease state:

• MSRV 1.83: const_mut_refs stabilization
• der v0.8.0
• hybrid-array v0.2.0
• rand_core v0.9.0: Tracker: rand 0.9 rust-random/rand#1165
• serdect v0.3.0
• Int feature tracking ticket #700
• Update method names to better match core
  • Naming conventions for widening/split operations #537
  • Adopt core naming conventions for bigint methods #693

[tarcieri]

With a prospective MSRV of 1.83 already, and the 2024 edition set to be stabilized in Rust 1.85 on 2025-02-20, I'm wondering if it makes sense to wait for that as well: https://doc.rust-lang.org/edition-guide/rust-2024/index.html

Notably edition bumps are a time where the entire ecosystem makes a more concerted effort to bump MSRV.

[dvdplm]

My two cents on this is: don't wait.

Let the bigint project be its own thing and release when it's "internally" logical to do so. One option is to let the MSRV bump be a one-feature release (i.e. release 0.6 without const_mut_refs and then make a 0.7 with the MSRV bump).

[tarcieri]

Rust 1.83 is coming out on November 28th, a week away. We can at least wait for that.

A release thereafter might make sense.

[ycscaly]

Hey @tarcieri any update as to the release date? Also, is there a changelog?
Rebasing my code on 0.6.0-rc.6 proved a difficult and worrisome task, with many surpising breaking changes:

• using u32 for bits instead of usize
• multiplication with * is not wide anymore
• shift operations with << etc has changed their functionality
  Honestly, my code "works", but I am very much afraid hidden somewhere deep inside is a bug that simply isn't cuaghet by any tests that was introduced because of a breaking change I wasn't aware/didn't understand its signficance.

I'm not sure if the original plan was to make such a hard-breaking release, and if you knew it would take so much effort to be upgraded, but in any case a thorough changelog that explains the breaking changes and their implications would ease my mind a lot.

[fjarri]

The only changes that won't be caught by the compiler, as far as I can tell, are:

• Some code may get slower because the methods that should have been constant-time but weren't, now are
• Some code may panic where it previously didn't (specifically when bit shifts are overflown)

But I agree that, in retrospect, it would have been nice to keep a synchronous changelog and not just rely on commit messages.

[tarcieri]

The main blocker at this point IMO is a rand_core update, which we'd like to do across the @RustCrypto ecosystem. Here's the tracking issue for that: rust-random/rand#1165

We could potentially do a release without those and other version bumps outlined above since I do know this release has been somewhat long-in-the-tooth.

Regarding changelogs, I typically manually curate them by going through the PRs/issues one-by-one, categorizing them, and trying to write short synopses which are sometimes the commit message (but often not) which ensures a consistent style. I haven't done that yet for v0.6, however we definitely ensure we have a changelog with every stable release.

I find collecting changelogs inline to be somewhat problematic as they're a huge source of merge conflicts.

[fjarri]

I find collecting changelogs inline to be somewhat problematic as they're a huge source of merge conflicts.

That hasn't been my experience. If there's an automatic merge conflict (rarely), it's easy to fix by hand since it's just an itemized list of freeform text and not complicated code.

[tarcieri]

It's still very annoying, IMO. I've seen projects adopt tooling to collect the changelogs in separate files just to avoid this problem.

[ycscaly]

The only changes that won't be caught by the compiler, as far as I can tell, are:

• Some code may get slower because the methods that should have been constant-time but weren't, now are
• Some code may panic where it previously didn't (specifically when bit shifts are overflown)

But I agree that, in retrospect, it would have been nice to keep a synchronous changelog and not just rely on commit messages.

I tend to disagree with this analysis; firstly, the behaviour of shifts is different (I can look it up but think the previous default was overflowing, and when overflow occurs it returns 0, whereas now it panics: potentially some code can depend on a returned 0 in overflow in a safe and planned way, so panicking there would cause a bug.)

Additionally, multiplication once was default widening, now overflowing/panicking. This might get caught by the compiler and might not, depending on how the returned value is used and how explicit the code was to begin with regarding the size of the number)

Now even panicking could be an issue: personally, I don’t believe in panicking, all my code returns result and doesn’t even call ‘unwrap’ and such unless it must and the result is guaranteed to work all the time. So an unexpected panic from an upgrade is an issue.

In any case, these are only the changes I’m aware of. Hopefully you’re right and there’s none other hidden, but definitely when the changelog comes I’ll have a good look at it to make sure

[fjarri]

Some code may panic where it previously didn't (specifically when bit shifts are overflown)

the previous default was overflowing, and when overflow occurs it returns 0, whereas now it panics

Seems like we agree on this one :) I think it'll be relatively easy to find too, you can just search for << and >> in your code and check if the rhs can be zero, or replace them with wrapping_ ops.