1.84.0 release post

[Mark-Simulacrum]

Rendered

[Mark-Simulacrum]

cc rust-lang/rust#133210 @lcnr @rust-lang/types -- I expanded/reworded a bit the stub you had started for new trait solver in coherence, would definitely appreciate review to make sure I didn't get the details too wrong :)

cc @joshtriplett @rust-lang/cargo for the section on MSRV-aware resolver, I sort of semi-randomly came up with recommendations and general prose but very happy to replace it if there's something better or actual recommendations the team wants to offer :)

cc @rust-lang/opsem for the strict provenance section -- I tried to find a balance between copying in the whole contents of the standard library docs and referencing them, very open to changes though.

[Mark-Simulacrum]

cc @rust-lang/release as well...

[jieyouxu]

cc @alex-semenyuk @traviscross for relnotes blog post (I am triagebot)

[weihanglo]

Instead of urging people setting MSRV, I might put focus on thinking their MSRV “policy” under a reasonable consideration, and then set the value.
Cargo doc does provide expectations and recommendations to help lib authors find their own policies, though I don't know how to put that properly in this paragraph 😞.

Anyway, thanks for writing this!

[RalfJung]

@Mark-Simulacrum I already spent some effort on Strict Provenance release notes in rust-lang/rust#131996, did you see that? I thought that is the intended place for such text.

[joshtriplett]

cc @epage

[Mark-Simulacrum]

@Mark-Simulacrum I already spent some effort on Strict Provenance release notes in rust-lang/rust#131996, did you see that? I thought that is the intended place for such text.

Thanks, I had seen it previously but missed it when putting together the blog (just my bad). Copied that text in, it looks good to me, thanks for writing it up!

[shepmaster]

“A toolchain”? “The toolchain”?

[Mark-Simulacrum]

This header isn't ideal IMO -- but I'm not sure adding an article will help. It's hard for me to succinctly describe what this feature is without using jargon (e.g., MSRV), especially since it's not on by default.

[epage]

If we want to provide more context on setting an MSRV, https://doc.rust-lang.org/cargo/reference/rust-version.html is where we have that documented and is fairly new so people are likely to have missed it

[Mark-Simulacrum]

I think we link that already in the first sentence?

[epage]

The difference is that is linking to it to provide context for the field while if we linked to it here, it would be to call out that guidance on MSRV policy exists. While the lead up sections are helpful, we could even link directly to https://doc.rust-lang.org/cargo/reference/rust-version.html#setting-and-updating-rust-version

As I said, "if we want to provide more context".

[epage]

(opening a new thread since #1451 (comment) is resolved and don't want this missed)

TODO: Should we talk about resolver v3 and/or recommend that as the path to enabling instead?

@weihanglo in #1451 (comment)

To me, setting it in manifest is a bit better than in config file. Not every project checks in .cargo/config.toml.

The emphasis should be on the config but with specific context.

It is true that we generally prefer project state to be in the manifest and transient state to be in the config file. This would generally be a project default that people would want to create a happy path for contributors.

However, if we only talk about the manifest, people will assume they can only use this feature if they bump their MSRV which would severely hamper the adoption of this feature as people with an MSRV are unlikely to bump it to gain access to this. We also need to acknowledge the config to ensure people know they can override this in CI for testing the latest dependencies.

[Mark-Simulacrum]

It's not clear to me what changes you're specifically looking for here (especially with a bunch of the rewording already done) -- maybe you can suggest something specific?

[epage]

The main focus of my comment is on emphasizing the config which is now done so people find a way to use this without bumping MSRV.

It would be nice to find a way to tell people that they don't need to bump MSRV to use this feature but I can't think of a succinct enough way of doing it.

We can probably mark this as resolved.

[epage]

With the new example, I feel like we can trim this down

Suggested change

	The new resolver will be enabled by default with the 2024 edition (expected to
	stabilize in 1.85), but can be enabled as of 1.84 by setting
	[`package.resolver = "3"`](https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions) in the Cargo.toml manifest file, or
	[`resolver.incompatible-rust-versions = "fallback"`](https://doc.rust-lang.org/cargo/reference/config.html#resolverincompatible-rust-versions) in the Cargo configuration file.
	The new resolver will be enabled by default with the 2024 edition (expected to
	stabilize in 1.85).

[Mark-Simulacrum]

I think the example doesn't reference Cargo.toml setting so this is probably still needed in the expanded form?

[epage]

Saying that it can opt-in with the config is redundant with the earlier section. That just leaves package.resolver which feels odd to leave dangling.

I posted an alternative suggestion at https://github.com/rust-lang/blog.rust-lang.org/pull/1451/files#r1902126387

Feel free to take that or close both

[Mark-Simulacrum]

OK, I think that incorporates the feedback I have clear solutions for. I'm still not super happy with the header for the MSRV section, but I don't have any better ideas than the tweak I applied just now.