rust-version and non-default features

[tomtau]

Currently, rust-version is set to 1.56 and it builds fine with default features.
During the release process, we found that at least 1.61 is required for --all-features.
Shall we set rust-version to 1.61?

[tomtau]

@CAD97 @NoahTheDuke

[tomtau]

Right now, it seems it's not possible to set different MSRVs per feature flags: https://rust-lang.github.io/rfcs/2495-min-rust-version.html#cfg-based-msrvs in the manifest?

[NoahTheDuke]

Related: #615 (comment)

[CAD97]

Also related: rust-lang/libs-team#72

Whilst it's not possible to key off of features, my opinion is that the rust-version should match the default feature set.

The ideal thing to do would be to downgrade the all-features MSRV, either by version sniffing or just changing what's adding the requirement.

Whatever we choose, we should test it in CI.

As far as if we want to bump MSRV again:

• We should add a policy for upgrading MSRV
• We should do a survey of rdeps's MSRV policies and avoid exceeding those
• We should also strongly consider a "six month" minimum even if no rdeps currently rely on that
• And track the T-libs discussion; it'll end up defacto setting the extended msrv policy for the ecosystem.

[CAD97]

direct rdeps

I checked rdeps with downloads >= 10k. Listed is just information from README/homepage/rustdoc; I did not check the rust-version key for any of these crates.

crate	msrv policy	notes
semver-parser	-	deprecated
handlebars	stable	patch-level change
nalgebra	stable	-
tera	-	no policy listed
json5	-	no policy listed
insta	-	no policy listed
mmids	-	no policy listed
async-graphql-parser	1.57.0	no policy listed; regularly bumped
termwiz	-	no policy listed
css-modules	-	only exists on crates-io; docs-rs and repo are 404
jsonpath-rust	-	no policy listed
liquid	-	no policy listed
py_literal	-	no policy listed
comrak	-	no policy listed
msi	-	no policy listed

I know @jhpratt has considered potentially using pest in time; time has an MSRV policy of six months, with a explicit hole allowed for optional interoperability crate dependencies.

[NoahTheDuke]

Thanks for the great research! 6 months is roughly stable-5, right? Seems like that's a reasonable bound given the discussion in the libs-team conversation.

[CAD97]

Yeah, 6 months is somewhere in stable-4/stable-5 (current stable is stable-0) since months aren't a clean number of weeks. stable-5 is cleanly always at least 6 months old.

[jhpratt]

Six months is ~26 weeks. So stable - 4, plus about two weeks buffer. I don't count the weeks though, as it's easier to just add six to the month, saturating the day if necessary. So August 31 would turn into February 28.

The six months policy is in relatively high use among popular crates with a formal policy. For pest being potentially used in the time crate, while it would be an optional dependency, it would not be so directly (basically there's no "pest" feature, just "parsing" that would rely on pest). As such the caveat would not apply, and pest would need to fully comply with my MSRV policy to be used as a dependency. This is, in part, why the only dependencies enabled by default are ones I directly control.

[tomtau]

FWIW:

• liquid appears to be on 1.59: cobalt-org/liquid-rust@831869a
• tera on 1.46: https://github.com/Keats/tera/blob/master/.github/workflows/ci.yml#L18 (but tera will abandon pest for a handwritten lexer/parser in its next version)
• insta on 1.56: https://github.com/mitsuhiko/insta/blob/master/Cargo.toml#L8
• termwiz on 1.57: https://github.com/wez/wezterm/blob/main/ci/check-rust-version.sh#L3
• py_literal on 1.42: https://github.com/jturner314/py_literal/blob/master/.github/workflows/ci.yml#L24

Anyway, the culprit non-default feature in pest that needs 1.61 is const_prec_climber (it previously required nightly).