Document MSRV policy and consider downstream packaging impact

[jdx]

Hi, this is feedback from a downstream packager / consumer of crates that depend on the AWS Smithy Rust stack.

Frequent MSRV bumps in smithy-rs-generated/runtime crates make it difficult to package software for distro channels like Fedora COPR and Ubuntu PPAs, even when the bumps are understandable from the project side.

To be clear, I'm not arguing that an MSRV bump must be treated as a semver-major change in the Rust ecosystem. In practice, Rust projects often do not treat MSRV changes that way.

The problem is that these bumps still have a real downstream cost:

• distro builders may lag current stable Rust
• packaging metadata has to be updated and coordinated across release targets
• a transitive dependency refresh can unexpectedly force a toolchain bump
• this can block or delay security fixes and routine package updates

Recent example from my side:

• updating AWS Smithy/AWS runtime dependencies to address a rustls-webpki advisory forced a repo/package MSRV bump from Rust 1.88 to 1.91
• that required checking and updating COPR/PPA packaging constraints in addition to the Rust dependency update itself

What would help a lot:

• a clearly documented MSRV policy for smithy-rs runtime crates
• explicit callouts in release notes when a release raises MSRV
• some indication of whether MSRV bumps are expected to happen freely in patch releases, or whether you try to batch/minimize them
• if practical, a little more caution around transitive dependency choices that force quick MSRV movement

I'm opening this mainly to make sure the downstream packaging pain is visible. Even if the answer is "we intentionally track recent stable Rust closely," having that policy documented would help packagers plan around it.

[landonxjames]

a clearly documented MSRV policy for smithy-rs runtime crates

It could probably be more clear and split out of the Setup section, but our MSRV policy is documented in the README of this repo:

The MSRV (Minimum Supported Rust Version) for the crates in this project is stable-2, i.e. the current stable Rust version and the prior two versions. Older versions may work.

explicit callouts in release notes when a release raises MSRV

We should definitely do better about this. I'll talk to the team.

some indication of whether MSRV bumps are expected to happen freely in patch releases, or whether you try to batch/minimize them

We've been trying to stick pretty closely to our documented stable-2 policy, although we do slip occasionally and bump several versions at once when we are busy with other work.

if practical, a little more caution around transitive dependency choices that force quick MSRV movement

We typically prioritize dependencies based on runtime/compile time performance before anything else. MSRV bump cadence is a secondary consideration, unless the crate always updates to stable as soon as it is released it hasn't been much of an issue. I understand it causes pain for some downstream consumers, but generally with the speed at with Rust releases versions and most customers update this has been a worthwhile tradeoff.