Define a MSRV Policy

[Skgland]

Currently scryer-prolog defines a msrv of 1.77¹.

In the past it has been occasionally bumped when someone wanted to use functionality only available in never versions or when updating dependencies and those required an msrv bump.

Why define an MSRV Policy

• reduce uncertainty for contributors²
• reduce uncertainty for users³

Why not define an MSRV Policy

• the project is still experimental and under heavy development and doesn't want to make promises it can't hold or will slow it down
  • not guaranteeing that we stay at a specific msrv until some predefined point could also be a policy

Why update the MSRV

Currently there are a few issues (open) that would require an msrv bump (or the use of a polyfill)

• unsafe keyword deemed unnecessary by compiler at build #2781 Remove unsafe block deemed unnecessary by compiler #2782 remove unsafe block that is not required in 1.82+
  • can also replace addr_of{,_mut}(<place>) with &raw {,mut} <place>
• Consider rust's strict_provenance? #2019 use strict_provenance stabilized in 1.84
• all things stabilized between 1.77 and whatever new msrv we might decide on⁴

Why not to update MSRV

• Leaves people stuck with old compilers behind.
• Debian is currently at 1.63⁵
  • Upcoming release trixie is currently⁶ at 1.83⁷

Footnotes

1. the package.rust-version key in Cargo.toml ↩

2. (new) contributors don't know which changes are acceptable https://github.com/mthom/scryer-prolog/pull/2782#issuecomment-2600862135 ↩

3. In Relax version constraint on reqwest dependency  #2491 lucksus was stuck with an old reqwest version, could as well have been an old rustc version ↩

4. https://releases.rs/ ↩

5. https://packages.debian.org/bookworm/devel/rust-all ↩

6. might still change till the not yet scheduled release ↩

7. https://packages.debian.org/trixie/rust-all ↩

[bakaq]

I think there is merit to the idea that Scryer Prolog is still too experimental to set a MSRV policy, and it's also a project that benefits a lot from new and upcoming features that may take a long time to get properly established in the slower distros because of its use of unsafe and custom allocators. My intuition is that we should periodically bump MSRV for useful new features like strict provenance and eventually custom allocators, because when Scryer Prolog is stable enough for us to slow down we will probably be using a particular version for long enough without needing to bump that it will happen to be well supported anyway.

That would mean giving up (or at least making it quite a bit harder for packagers) Debian packaging for the time, which is very relevant. That doesn't mean that Scryer Prolog will be inaccessible from those distros, just that it probably won't be packaged officially, like it is now.

I may also be misunderstanding how Debian packaging works in relation to MSRV. I've been assuming that they bootstrap all the Rust crates from their Rust package, so that would be the maximum MSRV for something to be packaged in Debian and anything higher would need to be patched to fit. But it may well be that they are allowed to bootstrap any Rust toolchain version and therefore MSRV isn't a problem. I've heard about shenanigans like this happening in Debian before, like with the Hyprland Wayland compositor which uses a different wlroots version from everything else, but I've not been able to find any definitive guidelines in Debian contributor documentation, so until someone more familiar with Rust packaging in Debian can clarify this I would assume they have the stricter policy.

[triska]

Regarding Debian, there are good news: There has recently been progress towards a draft package of 0.9.4:

https://linux.debian.bugs.dist.narkive.com/PdnYksXM/bug-1009086-rfp-scryer-prolog-an-open-source-industrial-strength-production-prolog-implementation#post3