RFC: Tealdeer MSRV Policy

[dbrgn]

Right now Tealdeer has a "bump it once we need it" MSRV (Minimal Supported Rust Version) policy. However, the question arose whether this makes sense or not.

As an application (as opposed to a library), there is less of a problem if we always follow stable Rust. The main concern would be distro packaging. If we always jump right on the latest version, we'll make the life harder for packagers.

Right now, according to https://pkgs.org/search/?q=rustc, the following rustc versions are distributed:

• Debian 10 (released): 1.41
• Debian 11 (testing): 1.48
• Ubuntu 21.04 (latest): 1.50
• Ubuntu 20.04 (LTS): 1.41
• FreeBSD 13: 1.51
• OpenSUSE Leap 15.2: 1.43.1

I'm not sure how much effort it is for distro packagers to use a newer rustc when building packages. Right now tealdeer is packaged in the following non-rolling-release distros:

• Fedora
• FreeBSD
• NetBSD
• OpenSUSE
• Solus

---

I see a few options:

1. Always track current stable

• This is most convenient for tealdeer developers

2. Support the lowest version that we can with our current set of dependencies

• Dependencies often upgrade the MSRV even in patch releases. This is something I hate, but it's the reality. It's a lot of work to guarantee a fixed MSRV.
• Bumping the MSRV only if a dependency forces us to, or if there's a feature that we really want, does not cause us developers a lot of trouble, but may help packagers. However, there can still be cases where a distro-shipped rustc is too old to build tealdeer.

3. Support "stable + n" versions

For example, if we pick "stable + 4", we'd be able to support building on any system that has a rustc which is not older than half a year. With "stable + 2", we'd be able to support building on any system that has a rustc which is not older than 3 months.

• This gives distributions some time to catch up with Rust packaging
• For the developers it means that all new features can be used, just with a bit of a delay

4. Support the version that latest mainstream distros (e.g. Debian, Ubuntu, Red Hat) support

• Most convenient for packagers
• This might mean that we'd need to actively pin dependencies to guarantee the MSRV, it's quite an effort

---

Since tealdeer isn't exactly a critical project, I'd be against 4, unless there are compelling reasons for it.

Always tracking stable (1) is convenient, but usually it's very little effort for the developers to support a few more versions of rustc, and it can avoid a lot of pain for packagers.

Right now we're roughly following 2. I'd tend towards picking 2 or 3 for our future MSRV policy.

What are your thoughts, @niklasmohrin @dmaahs2017?

[niklasmohrin]

Oh, right, I totally forgot about packaging. Woops

I agree with making life easier for packagers, I have to wonder whether having an "hard" msrv really helps.

1. I would believe that the best experience for the end user is always archived with the latest compiler, because it includes the most recent optimizations
2. We don't release that often. Packagers don't really need to keep up with us, because with every release of tealdeer, several compiler versions have been released in the mean time and the latest compiler the packager has installed might well be older than say 3 months
3. updating rustc is easy. If I was to package tealdeer binaries, I would just update to the latest stable and avoid all the trouble

That said, I have never been in the place of a packager and have no idea whether these thoughts line up with reality

I also dont know about any rules that these package bases lay out.

Maybe we could reach out to some of our packagers and get their input to decide what to do

[dbrgn]

Regarding 3, you're often bound to the version offered by the distro packaging toolchain and cannot simply use rustup to install the latest rustc.

I contacted a few of the packagers via e-mail, maybe some of them will leave a comment here 🙂

[decathorpe]

Hi! Speaking for Fedora:

We only have latest stable Rust + Cargo available, usually within days of it being released. So bumping MSRV is not an issue for us. On the other hand, projects sticking with a very old MSRV are sometimes burdensome for us, because that means either keeping additional old versions of libraries around, or patching projects to allow newer versions of dependencies because we don't care about support for old Rust compilers.

[dmaahs2017]

I don't have much of a preference. I'd say defer to what works best for packagers. But like @niklasmohrin said, we don't release that often so it's unlikely we release right after a new version of rust is released before that version is available for packagers.

[Staudey]

Hi there, and thanks for inviting me to the discussion via email!

For Solus we try to keep up with the latest stable Rust version. If you give us half a month or so after the release of the stable Rust version then we should usually have it available. i.e. we're not as fast as Fedora (see above) due to lacking manpower, but try to keep it reasonably up-to-date. Case in point, right now we're still at version 1.51, but it shouldn't take too long for that to change.

By the way, Solus IS a rolling release distro, contrary to what you wrote above 😉

[dbrgn]

@Staudey thanks for the correction, I wasn't aware that Solus has a rolling release model 🙂

From the feedback so far, I'd suggest the following as MSRV policy:

MSRV policy: When publishing a Tealdeer release, the Rust version required to build it should be stable for at least a month.

But let's wait another day to see if there's more feedback coming in.