The next MSRV bump

[djc]

Apart from syn 2: strawlab/iana-time-zone#91 updated its MSRV from 1.38 to 1.48, so unless we pin iana-time-zone we can no longer maintain our 1.38 MSRV for 0.4.x (which is our currently active release branch). The PR also started using windows-sys (which has a 1.48 MSRV) instead of winapi, so it's not trivial to revert to 1.38. @Kijewski and @astraw, would you consider pinging me on future MSRV bumps?

A few days ago, syn 2 was released, with an MSRV of 1.56. Current serde versions depend on syn 2, so we can no longer support serde on our current MSRV. Additionally, iana-time-zone-haiku depends on cxx and cxx-build, cxx depends on cxxbridge-macros, and both cxx-build and cxxbridge-macros depend on syn 2, so iana-time-zone-haiku now also effectively has a 1.56 MSRV. That doesn't necessarily need to affect other platforms, though isolating CI tests from platform-specific dependencies is a bit of a pain.

All things considered, I feel like anything pre-1.56 is pretty much dead in the water at this point, so I'm inclined to bump the MSRV to 1.56 for the next chrono 0.4 release. @esheppa any thoughts? @alex do you have any newer numbers on Rust version adoption in the Python ecosystem/among cryptography users?

[alex]

The script I had for summarizing data broke, but at any rate...

Our current MSRV is 1.48; our next release deprecates that, and announces that the following release will have an MSRV of 1.56. So we think going at least that far is fine.

[Kijewski]

Sorry, I only looked at chrono's Cargo.toml in the source, not what is actually currently used on crates.io, and I wrongly assumed you are already using windows-sys. :-/

But is iana-time-zone's MSRV bump actually going to be a problem for this project? #980 made it so that iana-time-zone is only used in cfg(unix), and the msrv is only increased for cfg(windows). So I guess unless a windows targetting project is using an old chrono<=0.4.23 and a new iana-time-zone==0.1.54, they should not be affected.

We will give your a heads up in the future if we intend to / need to bump our msrv!

[astraw]

@Kijewski and @astraw, would you consider pinging me on future MSRV bumps?

Yes, apologies that we did not do this in advance. This was an oversight on my part. I will attempt to ensure we do it differently next time.

[djc]

But is iana-time-zone's MSRV bump actually going to be a problem for this project? #980 made it so that iana-time-zone is only used in cfg(unix), and the msrv is only increased for cfg(windows). So I guess unless a windows targetting project is using an old chrono<=0.4.23 and a new iana-time-zone==0.1.54, they should not be affected.

Ahh, this is interesting. So the reason I started looking into this is that CI builds are failing because of syn 2. So it looks like Haiku maybe counts as a Unix?

[djc]

Ah, so I think this happens because we have unconditional dev-dependencies on serde-derive and serde-json.

[Kijewski]

So it looks like Haiku maybe counts as a Unix?

It does:

$ rustc --target=x86_64-unknown-haiku --print=cfg
debug_assertions
panic="unwind"
target_arch="x86_64"
target_endian="little"
target_env=""
target_family="unix"
target_feature="fxsr"
target_feature="sse"
target_feature="sse2"
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
target_os="haiku"
target_pointer_width="64"
target_vendor="unknown"
unix

I guess this is matklad/once_cell#201 all over again. You are using serde only with a feature gate, we are using cxx only in cfg(target_os = "haiku"). But even if it is not actually used, the single line edition = 2021 in syn's Cargo.toml is breaking everything. IMO that's a severe bug in cargo, that we cannot do anything about downstream.

[riverar]

Is there any ecosystem data to suggest a MSRV bump is undesirable here? (I noticed the crate is also pre-release from a semver perspective.) Apologies if I missed some data/msrv policy somewhere.

[alex]

We have data for Python users of packages with Rust code, my script to aggregate them is broken however:-(

…

On Wed, Mar 22, 2023, 12:57 PM Rafael Rivera ***@***.***> wrote: Is there any ecosystem data to suggest a MSRV bump is undesirable here? (I noticed the crate is also pre-release from a semver perspective.) Apologies if I missed some data/msrv policy somewhere. — Reply to this email directly, view it on GitHub <#995 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBG7PLWHTX47FTC4QHDW5MVPZANCNFSM6AAAAAAWDRAFQU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jtmoon79]

Just FYI, possibly related build break in this PR #1000 (comment) (Job rust_msrv (ubuntu-latest))

[djc]

The CI failure was my reason to open this issue, yes.

[pitdicker]

If the MSRV could increase to not only 1.56 but to 1.57, that would allow a large portion of the current 0.4.x API to become const, including the parts that validate the date and time input and panic if invalid.

It would safe unwraps and quite some friction if NaiveDate::from_ymd and similar would be un-deprecated, and become available in const context. Any invalid input would just fail the compilation.

That seems like a huge selling point for a new release to me, and a good reason to increase the MSRV to a version of ca. 16 months old.

[esheppa]

@pitdicker the issue here is using things like NaiveDate::from_ymd with non const inputs so it would probably have to still be a new API rather than un-deprecating the existing API. It might also make more sense to use const parameters to ensure that the const validation is only ever run at compile time. Importantly, we can still have this in the code, just as an opt-in feature

[pitdicker]

@esheppa Sorry, I don't understand what you mean. Can you give an example?

Wat I have in mind with a test branch the following can work on 0.4.x with 1.57+:

const TODAY: NaiveDate = NaiveDate::from_ymd(2023, 5, 14);
const YESTERDAY: NaiveDate = TODAY.pred();
const TOMORROW: NaiveDate = TODAY.succ();
const TIME: NaiveTime = NaiveTime::from_hms(15, 10, 0);
const NOW: NaiveDateTime = TODAY.and_time(TIME);
const DATETIME2: NaiveDateTime = DATE.and_hms(15, 10, 0);

// An invalid date or time will fail to compile:
const DATE3: NaiveDate = NaiveDate::from_ymd(2023, 4, 31);

But since the comment you replied to I have come around a bit on NaiveDate::from_ymd. It makes sense for that method to return an Option or Result by default, because knowing whether a date is valid is not trivial (while for a NaiveTime it is).

But than it gets less nice to use:

const TODAY: NaiveDate = match NaiveDate::from_ymd_opt(2023, 5, 14) {
    Some(d) => d,
    None => panic!(),
};

How would code look like with what you have in mind?

[djc]

The problem is that, if we make the from_ymd() definition const, it can be called from both const and non-const contexts. While we're okay with panicking in a const context, we'd prefer not to expose methods that panic in a non-const context. As such, I don't want to just undeprecate the existing functions once we've made them const.

Anyway, we've bumped 0.4.x to 1.56 (in #1053, which also contains more discussion on the 1.56 vs 1.57 question) so going to close this.