Tracking issue for v0.4 release

[newpavlov]

List of potential breaking changes:

• Bump MSRV to 1.85 and edition to 2024
• Relax MSRV policy to allow MSRV bumps in patch releases, i.e. we would rely on the MSRV-aware resolver going forward
• Remove the wasm_js backend in favor of the custom fallback crate feature (also see Add feature-gated getrandom support wasm-bindgen/wasm-bindgen#4667)

It's arguably a good time to synchronize v0.4 release with the planned rand v0.10 release (which also bumps MSRV to 1.85).

Edit by @dhardy: strike out last TODO item (see here).

[briansmith]

Bump MSRV to 1.85 and edition to 2024

Why? I see no significant advantage of doing this.

Relax MSRV policy to allow MSRV bumps in patch releases

+1. But this could be done even in 0.3. No need for 0.4.

[newpavlov]

But this could be done even in 0.3. No need for 0.4.

No, it can not be according to the MSRV policy used in v0.3.

[briansmith]

No, it can not be according to the MSRV policy used in v0.3.

The MSRV policy for 0.3 can be changed.

[newpavlov]

We also can break semver compatibility. It does not mean we should do it.

I think it's better to just make a new breaking release and clearly inform downstream users about the change.

[briansmith]

OK. The proposed 0.4 release seems to only have negative effects, so I would expect many projects to keep using older releases, especially since I think ports and whatnot get back ported to older releases now.

[dhardy]

@briansmith your arguments would make sense for an interface crate like rand_core but the only interface for foreign code in getrandom is that to support custom backends, which IIUC are uncommon. I therefore fail to see why it matters much whether the next release is semver breaking? Is it just because inevitably some binaries will end up using multiple copies of getrandom (v0.3 + v0.4) for a while?

[briansmith]

The MSRV for my crate is 1.66. Some versions of 0.3 have an MSRV less than that. If all versions of getrandom 0.4 have an MSRV greater than that, then why bother switching from 0.3 to 0.4? (FWIW, currently I am using 0.2 for similar but different reasons.)

[tarcieri]

One nice thing about the higher MSRV is getrandom::Error now impls core::error::Error.

Without that (i.e. on getrandom v0.3) I was having to use a wrapper error type that impls core::error::Error, or else add a std feature

[dhardy]

I'd like to see a pre-release (full release is currently blocked by rand_core). But should this be 0.4.0-rc.0 or 0.3.5-rc.0?

The MSRV policy is a minor issue in my opinion: other crates have bumped this without a breaking version in the past since this was considered less problematic than making a new breaking release. Cargo supports using version ranges so really the question only seems to affect existing dependencies of getrandom v0.3.x. Is there any particular reason we'd want to support an automatic upgrade path for those? If not, then I think we might as well bump to v0.4.0 (which helps communicate the significant changes).

We could perhaps drop the MSRV, but the MSRV-aware resolver was only stabilised in 1.84.0. (This affects rand_core too, though the resolver is really the only significant thing there: rust-random/rand#1668.)

[tarcieri]

I could definitely also use a prerelease, one way or another. It's currently a blocker for us getting another release of crypto-common out, since we already migrated to the SysRng API.

[tarcieri]

But should this be 0.4.0-rc.0 or 0.3.5-rc.0?

My vote is for v0.4.0-rc.0. To get the core::error::Error impl on getrandom::Error you need at least Rust 1.81, and at that point might as well just go to 1.85 / the edition bump.

IMO one of the biggest reasons NOT to bump MSRV in the past was Debian stable, but that now supports Rust 1.85.

[dhardy]

My vote is for v0.4.0-rc.0.

With @tarcieri, @newpavlov and myself in agreement, we should go ahead with the 0.4.0 release number and make an RC.

I also don't see the wasm_js as an outstanding TODO item; it was decided here by @josephlr (with my agreement) to let wasm_js also imply wasm_js as the default backend on WASM (unknown variants).