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

[joshtriplett]

Suggested change

	1.84.0 stabilizes the minimum supported Rust version (MSRV) aware resolver,
	1.84.0 stabilizes the MSRV-aware resolver,

The acronym is explained by the link later in the sentence, and avoiding the expansion here allows hyphenating "MSRV-aware".

[Mark-Simulacrum]

Typically you want to introduce an acronym before you use it, right? I think if we change this we'd lose any direct equivalence statement (i.e., "expanded" = "MSRV") -- you'd have to click through to figure it out. MSRV doesn't feel that well known a term to me, so I think writing it out is better for the first reference.

[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.

[alex-semenyuk]

MSRV-aware

[jieyouxu]

Already mentioned here #1451 (comment)

[alex-semenyuk]

Yes, I meant line 26 as well

Suggested change

	dependencies, if available, to improve package version selection. Rust version
	dependencies, if available, to improve package version selection. MSRV-aware

[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.

[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).

[epage]

We've found some people assuming the MSRV-aware resolver will respect your current Rust version and not your package.rust-version. Instead your toolchain version is only a fallback for when your you don't set a package.rust-version.

Suggested change

	which uses the declared [minimum supported Rust version](https://doc.rust-lang.org/cargo/reference/rust-version.html) from
	dependencies, if available, to improve package version selection. Rust version
	which prefers dependency versions that have declared a [MSRV](https://doc.rust-lang.org/cargo/reference/rust-version.html) that is compatible with your project's MSRV. Rust version

(switched the link to use the acronym since it is now introduced earlier)

Similarly, I wonder if the title will encourage this misunderstanding but don't have much of a suggestion.

[epage]

The MSRV section focuses only on the effect on library authors and only in adopting newer MSRVs. This also helps those still supporting old versions and for application authors who need to target older toolchains. Since we cover the freedom this buys library authors later on, maybe we can remove this section for focus on the more immediate improvement.

Suggested change

	dependencies, if available, to improve package version selection. Rust version
	aware selection allows library authors to easily adopt newer Rust versions
	while avoiding breaking consumers needing compatibility with older toolchains.
	dependencies, if available, to improve package version selection. With MSRV-aware version selection, the toil is reduced for maintainers to support older toolchains by not needing to manually select older versions for each dependency.

[epage]

While I would love for library authors to bump their MSRV more aggressively (maybe some packages can finally drop Rust 1.31 support...), I feel like this prescriptive language might be off putting to people who support an older MSRV.

Maybe if we replace this with the talk of flexibility that comes later

Suggested change

	Library authors should take the MSRV-aware resolver into account when deciding
	their policy on adopting new Rust toolchain features. Previously, a library
	adopting features from a new Rust toolchain would force downstream users of
	that library who have an older Rust version to either upgrade their toolchain
	or manually select an old version of the library compatible with their
	toolchain (and avoid running `cargo update`). Now, those users will be able to
	automatically use older library versions compatible with their older toolchain.
	In the future, we expect this to provide more flexibility for library authors
	to select their preferred support strategy for Rust versions, with the toolchain
	helping users on older toolchains avoid breakage.
	This gives library authors more flexibility when deciding
	their policy on adopting new Rust toolchain features. Previously, a library
	adopting features from a new Rust toolchain would force downstream users of
	that library who have an older Rust version to either upgrade their toolchain
	or manually select an old version of the library compatible with their
	toolchain (and avoid running `cargo update`). Now, those users will be able to
	automatically use older library versions compatible with their older toolchain.
	See the [documentation](https://doc.rust-lang.org/cargo/reference/rust-version.html#setting-and-updating-rust-version) for more considerations when deciding on an MSRV policy.