Possible LTS releases tied to editions?

[gbutler]

@cuviper

It may well be that the “Rust Community Sponsored/Supported LTS” would be primarily driven by packagers

So, perhaps this argues for the formation of a "Rust Packagers" Working Group and that the concept of a Rust LTS would fall under its auspices?

[vi0]

Maybe LTS release would be more useful with more stable Rust ABI?

That would allow System Rust Library to be available for distributions.

[gbutler]

@vi0

Maybe LTS release would be more useful with more stable Rust ABI?

I don't think I understand, if the idea that a Rust LTS would consist of some fixed compiler version with only bug/security fixes, how that would be truly relevant? I understand, that even a bug-fix bump to the version of the compiler would (today at least, I'm not sure) cause a corresponding change to the hash that is appended to public symbols in the object files through symbol-mangling, but, that seems like something that could be easily addressed by having the hash ignore bumps to the bug-fix part of the version number (if it doesn't do that already).

[H2CO3]

Sure, and then nobody would use it because “it uses deprecated features” and “it doesn’t move with the flow”. Certainly, in an ideal world, we wouldn’t need such “official confirmation” of support for an “old” version, but… we don’t live in such an ideal world, and people are hopelessly hype-driven. Anyway, I don’t think it’s worth arguing more about it at this point, we seem to disagree and not willing to change our minds.

[hsivonen]

@rpjohnst

there will still be logistical problems. In a large organization, you have a bunch of dev machines, a bunch of CI infrastructure, etc. and it all has to be updated at the same time because Rust’s ABI is unstable.

I guess there's always a larger organization, but I expect Mozilla to qualify as "large" as far as Rust goes. The way Firefox CI works is similar to how Travis works: There's an in-repo configuration file that declares the Rust toolchain, so all CI VMs can be directed to use a new toolchain by editing in-repo configuration. Likewise, in-repo build system code declares the minimum Rust version required to build, so the way things work on dev machines is that if a developer's local Rust installation falls behind what the in-repo build system declaration requires, the build system complains and then the developer runs rustup update. (If it was deemed necessary, which it doesn't appear to be in practice, the build system could mandate a more precise Rust version on dev machines instead of just requiring a minimum version.)

Considering that these issues are solvable and have been solved in a large project, it seems like a bad use of the crate authors' collective effort to enable some organizations not to solve these issues properly.

[hsivonen]

@gavento

how often is it necessary to avoid updating to a new major GCC version to avoid some breakage?

I don't drive compiler updates for Firefox, so what I know is just what I can see in dependencies and review requests on Bugzilla. However, it appears that just about every major GCC and clang requires some changes to Firefox. It appears that the vast majority of issues is a matter of the compilers adding new diagnostics and changes are required not to trigger the new diagnostics so as to keep the build clean of warnings. The next class of changes seems to be making sure that the compiler can be updated without accidentally requiring GNU C++ standard library symbols that users' older systems won't have. (Thanks to Rust's standard library getting bundled with the app, this type of issue isn't relevant to Rust.)

And then there's an occasional more serious actual bug or not an outright bug but something that looks enough like a bug on valgrind or the sanitizers to need action.