Add MSRV policy about gleam

[lpil]

I don't want to encourage package maintainers to only ship very old versions of Gleam so I don't see any advantage to adding this. It seem to be a lose for everyone, from the maintainers (more to worry about), for users (confusion as to why their version doesn't have everything documented, hard to install a current version), and for us (extra support workload due to outdated packages).

We only make changes if we have clear benefits such as unlocking something new, or reducing our workload, so I'm going to close this. If you have an idea for how this Cargo feature could be used to make things easier for us then feel free to open a new issue. Thank you

[dahlbaek]

I opened a pr that sets rust-version to 1.71.1 in #3160.

[lpil]

We could do this, but it would always be set to the latest version, and we'd need a CI job that ensure that the version specified is the latest version of Rust. Older versions are not supported.

Would this be useful? I'm unsure how it helps with packaging.

[dahlbaek]

To be honest I don't have much experience packaging for distros (i.e. this is the first time I seriously considered contributing something to a distro), but as far as I can tell, it would be useful because it makes it very easy to know which version of gleam to package for a specific release. I.e., you just determine the version of rustc which is packaged with a given release, and the you find the latest version of gleam which supports that version of rustc. If that information is not made available through meta-data such as rust-version, the packager needs to determine that information themselves, without the compiler pointing them in the right direction.

For this "first round" of packaging in debian, it would be useful if rust-version could be set to 1.71.1, but even if that's not a possibility I think it'll be useful as time passes, so packagers can always determine which version to target for their given distro release.

[dahlbaek]

If the decision is that rust-version can be added only on the condition that it always refers to latest stable version of rustc, I'll be happy to look into implementing that in place of #3160

[lpil]

For this "first round" of packaging in debian, it would be useful if rust-version could be set to 1.71.1, but even if that's not a possibility I think it'll be useful as time passes

We will not be expanding the officially supported version.

Overall this sounds like it would make it harder for the maintainers? Rather than being able to try the version of the compiler they have available they would be forced to use what we officially support, which would introduce a lag of perhaps years before they could get a Gleam version in their repo. That sounds like it would make the package useless in any practical sense, seeing as it's purely a development tool.

[dahlbaek]

Overall this sounds like it would make it harder for the maintainers? Rather than being able to try the version of the compiler they have available they would be forced to use what we officially support, which would introduce a lag of perhaps years before they could get a Gleam version in their repo.

As a package maintainer, you can always choose to build with --ignore-rust-version and see how it works out. So adding rust-version will never make it harder to package gleam.

That sounds like it would make the package useless in any practical sense, seeing as it's purely a development tool.

I think one of the main purposes of development tools is to build things you want to share with other people. In order to share anything built in gleam via the debian main component, the gleam compiler has to be present in the debian main component. In this sense I don’t think gleam is fundamentally different from go, rust, erlang, elixir or any of the other compilers you find in the debian main component 🤔 but maybe I’m missing some part of the bigger picture?