Please don't bump MSRV in patch versions

[Xuanwo]

Hi, the latest version of time increases MSRV in commit c45264c to 1.62, which can break projects whose target MSRV is lower than v1.62.

For example: https://github.com/datafuselabs/opendal/actions/runs/4202370308/jobs/7290435436

How about delaying this change and moving it to the next minor release? Many thanks in advance.

Related to: #535

[jhpratt]

As time is pre-1.0, the next "minor" release is a breaking change. As such the only options are to not bump MSRV at all (which is unacceptable) or bump it in a patch version. Once time eventually reaches 1.0, it will only be bumped in minor releases.

The MSRV policy of time has long been six months of compiler support. If there is a need (not want) for non-trivial lengths of time, please leave a comment in #535. Other crates having their own MSRV policy is not sufficient reasoning.

[Xuanwo]

Thanks for the explanation! I totally respect your decision.

And hey, just in case anyone else runs into this problem, let's make sure we specify the dependencies as follows:

# time 0.3.18 bump MSRV to 1.62 
time = "<=0.3.17"

[zeenix]

As time is pre-1.0, the next "minor" release is a breaking change.

That is true but didn't you bump in the micro release? The workaround @Xuanwo mentioned above won't be needed at all if semver rules were followed. i-e Cargo will not pick version 0.4.0 if dep is specified as time = 0.3.0 in the Cargo.toml file.

FWIW, this broke our CI today. I thought I'll bite the bullet and bump our MSRV but then I found out that 1.62 is not even packaged in Ubuntu 22 so I'm reluctant to do that.

I could pin the version of time but the only reason my crate (optionally) uses time is to provide an impl of a trait and me pinning the version would either mean they can't use that impl or also pin time's version.

[jhpratt]

That is true but didn't you bump in the micro release?

If by "micro" you mean "patch", then yes. I stated why this is necessary in the very next sentence.

FWIW, this broke our CI today.

That is because you incorrectly assumed that time's MSRV was static. Very few crates have static MSRVs — almost all have a policy of some sort (even if not stated).

---

Please do not turn this issue into yet another discussion on MSRV. There is #535 if you have anything to add.

[zeenix]

If by "micro" you mean "patch"

Yeah, "patch" is just the fancy new word for it.

That is because you incorrectly assumed that time's MSRV was static.

The only assumption I made was that no depending crate will bump their MSRV in a micro release, to a version not yet even available in latest Ubuntu LTS.

Very few crates have static MSRVs — almost all have a policy of some sort (even if not stated).

Sure, we'll be bumping our MSRV too. No other dependency (we've quite a few) has so far broken our CI though.

Please do not turn this issue into yet another discussion on MSRV. There is #535 if you have anything to add.

I'm a bit surprised by a lack of empathy here. I explained why this is a problem for me and you are blaming me for making assumptions and derailing the discussion. 😔

[zeenix]

Anyway, don't think this will be leading to anything productive so I'm unsubscribing.

[jhpratt]

@zeenix Please use #535 as indicated. I merely do not want to have duplicate conversations.