toolchain policy

[danieleades]

I have a question about this project's toolchain policy. I can see that this project specifies a fixed toolchain version. Can I ask why Fornjot needs a fixed toolchain? As opposed to say, continuous testing of the latest stable release? I understand that testing against a rolling release is generally more important for a library than a binary, but i'm just curious what the benefit is in this case.

[hannobraun]

I'm using the latest stable version to develop Fornjot (usually I upgrade within days of a release), and for at least the last two releases, I've started using newly stabilized features pretty much immediately. So for at least the last few months, it wouldn't have been possible to use an older version than the one specified in rust-toolchain.toml.

What I like about rust-toolchain.toml is that it's a single place where I can change the version to just make everything work. It documents what version can be used to compile Fornjot, it updates the CI build, and if I do some work on my laptop on the weekend, the compiler will automatically update (so I don't have to wonder why suddenly there are errors).

This works well for me. If there's a problem with this approach (as your question seems to imply), I'd love to hear it! And of course I'm open to suggestions on how to do things differently.

[hannobraun]

Addendum: I also remember running into some bug with the latest stable version a while back, and back then we used rust-toolchain.toml to pin to the latest working version.

But unless that happens again, just using the latest stable version on CI (maybe in combination with rust-version in Cargo.toml) should pretty much have the same effect, minus the inconvenience of forcing the user to download a different toolchain.

[danieleades]

the other approach is to define a minimum supported rust version (MSRV) which is the oldest compiler version that the repo supports. You would then use CI to test both the latest stable or nightly version, as well as the MSRV version.

It's a nice workflow, but on reflection it's probably much more suited to libraries rather than applications, since you want to impose the minimum restrictions on downstream users, and cut a new release when that contract changes. For an application you probably don't care so much, since you "ship" a compiled package.

The rust-version in Cargo.toml is used for setting the MSRV, so I don't think it's appropriate for this repo as it stands, since the toolchain set in the rust-toolchain.toml file is not the minimum, it's just some fairly recent 'blessed' version.

[hannobraun]

the other approach is to define a minimum supported rust version (MSRV) which is the oldest compiler version that the repo supports. You would then use CI to test both the latest stable or nightly version, as well as the MSRV version.

Please note, the version in rust-toolchain.toml usually is the MSRV. The code base is currently using let-else and one GAT, both of which are only available in the latest release.

It's a nice workflow, but on reflection it's probably much more suited to libraries rather than applications, since you want to impose the minimum restrictions on downstream users, and cut a new release when that contract changes. For an application you probably don't care so much, since you "ship" a compiled package.

Well, Fornjot is a set of libraries too, so a proper MSRV policy makes sense, in principle. I think it's too early for that though, without any users (that I know of) of the libraries outside of the Fornjot application itself.

Supporting older versions is a burden in terms of development (not having access to features that would help) and CI (turnaround time and resources used). I'd rather avoid that burden, until there is a clear benefit that would offset it.

The rust-version in Cargo.toml is used for setting the MSRV, so I don't think it's appropriate for this repo as it stands, since the toolchain set in the rust-toolchain.toml file is not the minimum, it's just some fairly recent 'blessed' version.

As I said, it usually is the minimum. For example, I've started using let-else on the day I upgraded last time.

[hannobraun]

I'm going to convert this issue to a discussion, as it doesn't track any pending work.