Mmm, serde is part of the problem, it seems? Another approach is to have a different MSRV for the "base" crate vs the with serde features.

Thinking through your idea; would this imply that folks concerned about their build chain, presumably the ones using MSRV, do not get access to serde? Is that feasible? Is it meaningful to only guarantee a conservative MSRV for "std" and "no-std" with no other features? This would make introducing usage of crev significantly easier because we could limit the crev'ed dependencies in the same manner.

We'd have to conditionally include dev dependencies (I forget how but I vaguely remember there is a way). Dependency graphs posted below.

We'd still have some MSRV for serde folks, just a different one from more general users.

I'm a little hesitant to say "the MSRV is higher if you enable dependencies" when the only breaking changes are in the dependencies themselves, and users can just work around them by pinning. If we were to actually conditionally bump our own MSRV, we could wind up breaking things in our own code without realizing. So we'd start with an MSRV policy that was actually much looser than reality, and initially Debian people wouldn't even notice, and then one day we'd break them and they'd get upset.

As Matt says, at some point we wind up having pinned everything ... and even with all features on we don't have very much to pin. It's basically just serde. (Remember that rand and base64 are both on old major versions, so we don't expect any new changes from them ever.)

For the default you can see that, outside of dev-dependencies, we depend only on cc (which has only broken MSRV a couple times) and libc (which hasn't ever broken us). With no-std we additionally have core2, memchr, and for same reason hex_lit (which we should get rid of since we have hex-conservative).

So I think the MSRV burden for the "no extra features" case is pretty low.

messing with version requirements was not fruitful. (and it was tedious)...

Tell me about it! I do it manually and it is miserable. That is the main reason for raising this discussion :)

For fun (self torture) I tried it with 1.41 toolchain, and I think it had me using a 3 year old tokio or something like that...

I guess some dependencies are just not viable for libraries that care about MSRV... you need to only use libraries that care about MSRV if you want to care about MSRV...

And even then, the dependencies might have a more liberal view of bumping MSRV... some crates view it as a non-breaking change and will break MSRV in patch versions... ugh...

FWIW, tokio actually does care about MSRV, just may not always fix it if a dependency of theirs breaks it (but usually its okay, as long as you dont use the macros feature). It supports 1.49 with even the latest LTS.

To get more traction, I do feel that a lot of our time is "wasted" in fixing dependencies for MSRV. I would personally prefer a 2021 version if that fixes our MSRV issues for the foreseeable future.

@sanket1729 I think we've had repeated problems with serde_derive and I can't recall a single other problem. (More specifically syn has mostly been giving us grief except for that one time when serde_derive itself started shipping a binary blob. syn is a dependency of serde_derive.)

I think it'd save us 95% of the wasted dep-fixing time to just drop serde_derive. And I'm unconvinced that any finite MSRV would stop the syn pain otherwise.