Make MSRV explicit & check accidental bump in the CI

[zeenix]

• Formatting fixes to Cargo.toml
• Declare MSRV in Cargo.toml
• Run a job against MSRV

[sgued]

Please mention a policy in the README.

I think we can decide that bumping MSRV is not a breaking change, but that we aim for one version before stable.
That way it's currently valid, should be enough for downstream not to get to badly surprised and should be easy to maintain.

[zeenix]

I think we can decide that bumping MSRV is not a breaking change

Theoretically it's not but consider that bumping MSRV can break downstream builds w/o any changes downstream, I really think it should be considered at least a very light breakage and hence we should try to only bump it when necessary.

, but that we aim for one version before stable.

Most Rust devs, just use the latest Rust (if not nightly) so too new MSRV is mainly a problem for Linux distributions. Keeping that in mind, a 1-2 month old release isn't going to be much different than requiring the latest release.

So I think we want to be sympathetic to distributions, we should then require no recent than 6 months old release. OTOH, if we decide not to care, we don't need any such policy and bump it to even the latest release whenever we need/want to.

[sgued]

I think bumping to latest stable can be troublesome if a heapless release happens just after a rust stable release, hence why I suggest going with the -1

Ideally we would target debian stable, but that is not possible with the current state of the library, and in the future we will probably want to benefit from coming improvements to const functions/traits, without having to wait 2 years for debian to catch them. Hence the suggestion to keep going with -1.

I agree that bumping MSRV for something that can be done without bumping MSRV should be avoided.

[zeenix]

Ideally we would target debian stable, but that is not possible with the current state of the library, and in the future we will probably want to benefit from coming improvements to const functions/traits, without having to wait 2 years for debian to catch them. Hence the suggestion to keep going with -1.

I agree that 2 years is way too long in the Rust world but if the ideal is to target Debian, then surely we should go with something that's along the way. :) That's why I suggested 6 months if we do sympathise with distro packagers. Most distros do update Rust tools in their LTE releases.

But I guess, what you're saying is that why bother if we can't meaningfully satisfy them anyway and I can understand that.

Another aspect I didn't think about before, is that this library is almost exclusively used for microcontrollers and hence the chances of it being a mandatory dependency of a system software, are low so perhaps until someone actually complains about MSRV being too new and giving them real problems, we can go with -1 policy, you suggested.

I agree that bumping MSRV for something that can be done without bumping MSRV should be avoided.

👍

[zeenix]

Please mention a policy in the README.

Done.

[sgued]

That's why I suggested 6 months if we do sympathise with distro packagers. Most distros do update Rust tools in their LTE releases.

I agree but the current MSRV is more recent than 6 months. If we get to the point where MSRV doesn't get bumped for 6 months I would consider making that promise. For now it's not possible.

[zeenix]

@sgued so good now?