Consider supporting an older rustc? ("MSRV")

[FauxFaux]

As a popular library that is used by other libraries, it would be convenient if rusqlite specified that it would work on some compiler for some "semver release"; a specification which moved slower than just "it works on stable". If not, writing that down (even if it's just here) would be cool too.

I'm not going to write a big essay on the advantages and disadvantages of this, as I'm not convinced either way myself.

As an example breakage, jgallagher@208f3c0 (Jul 10th), released Jul 27th, broke rustc <1.36, released Jul 4th. Based on the commit message, this wasn't (super) intentional.

1.34.2 might be a good thing to support initially, as it's currently recent (but not recent enough to build rusqlite), and it's what's in Debian (i.e. what I hit!). I would also be happy with just whatever's stable now, though.

[thomcc]

I don't think we really want to decide to support whichever version of rustc happens to be in popular Linux distributions. This will typically be a couple versions behind, and short of taking a survey of what various distributions use, will probably leave some out.

To be honest, I'd vote for just supporting 'latest stable', as AFAICT that's been the policy of this crate the whole time I've used it, and supporting older versions is additional work, but really this is probably something @gwenn should decide.

[gwenn]

@thomcc I agree with you.
Maybe we can edit release notes by checking Travis CI history and adding the stable version used ?

[FauxFaux]

Okay, all good!

Perhaps stating that 0.20.x will continue to support whatever was stable at 0.20.0? Not that there has ever really been a point release since 0.10.x.

[stevenroose]

It would at least be very helpful to show what actually is the oldest supported Rust version. By putting it in the README and enforcing it by adding it to the travis CI file.

This is an important factor to decide what crate to use, so it would be helpful if it was obvious right away.

[stevenroose]

Also related, breaking this MSRV should be considered a breaking semver change. Otherwise you can break other crates depending on this crate but having an older Rust version.

[tnull]

It's really unfortunate to hear that MSRV support is not planned. If projects need to maintain longer-term support, not having MSRV guarantees means they can't rely on a rusqlite dependency.

It would be great if you reconsidered this decision and would consider supporting at least a reasonable MSRV of 1.63 or so.

[thomcc]

Also related, breaking this MSRV should be considered a breaking semver change. Otherwise you can break other crates depending on this crate but having an older Rust version.

For a library, if you care about an MSRV it's only important that there exist a set of packages that satisfy the MSRV under your requirements, rather than have every possible set of packages under your satisfy the MSRV. The distinction means that you can enforce MSRV via a lockfile, at the point -- It's generally impossible to enforce this sort of thing without one. Concretely, can do something like cargo update -p rusqlite --precise $specific_version_here to ensure (if possible) that your Cargo.lock contains $specific_version_here for rusqlite, for example.

In practice rusqlite is not that aggressive about using new features anyway, and where reasonable we have a history of taking patches to make things work in older Rust.

See also rust-lang/libs-team#72 for more discussions on this topic. MSRV is considerably less simple than most people make it out to be.

[tnull]

For a library, if you care about an MSRV it's only important that there exist a set of packages that satisfy the MSRV under your requirements, rather than have every possible set of packages under your satisfy the MSRV. The distinction means that you can enforce MSRV via a lockfile, at the point -- It's generally impossible to enforce this sort of thing without one. Concretely, can do something like cargo update -p rusqlite --precise $specific_version_here to ensure (if possible) that your Cargo.lock contains $specific_version_here for rusqlite, for example.

Right, and I'm asking whether rusqlite itself could introduce a MSRV check in CI and, if necessary, introduce such pinning in CI itself to ensure it actually works and continues to work with the older rustc, even if its dependencies start bumping their requirements.

In practice rusqlite is not that aggressive about using new features anyway, and where reasonable we have a history of taking patches to make things work in older Rust.

That's great but unfortunately that's not a guarantee that things won't break as many packages have the habit of carelessly bumping MSRV requirements, leaving behind any downstream users that can't keep up. So even if rusqlite is conservative about introducing breaking changes, any of its dependencies might, and then it's up to the downstream user to figure out who's responsible and how to make all this mess work again. Adding a check in CI would help a lot as it would alert project maintainers of any code changes or dependency bumps that might break the guarantees.

See also rust-lang/libs-team#72 for more discussions on this topic. MSRV is considerably less simple than most people make it out to be.

Yes, I'm aware it can be tricky, but not caring at all is unfortunately not a solution either. The usual answer in the Rust ecosystem seems to be "what do we care, you should just upgrade to the latest stable, always" which just doesn't work in a lot of environments that require long-term support.

[TheBlueMatt]

See also rust-lang/libs-team#72 for more discussions on this topic.

Indeed, and while there are many diverse views in that issue, but the point of that discussion was to create a policy such that downstream users of the standard libc crate know what they can expect and can build a toolchain around it. I understood that to be the point of this issue - simply writing down a policy (and enforcing it in CI) so that MSRV breakage doesn't slip in without a conscious decision to do so (and preferably some rustc feature which makes the code substantially more readable, rather than "just because").