Possible LTS releases tied to editions?

[gbutler]

You’re clearly missing whatever it is that drives people to use LTS releases of their software, so maybe chill out for a minute and think it through.

Yes, I’m missing it because it hasn’t been clearly and logically articulated what the benefit of an LTS release is over the Editions. There is no hyperbole and no need to chill - no one is “heated” Just because someone disagrees with the proposal and doesn’t agree that you’ve made your case, doesn’t make things “heated” or “hyperbole”. In fact, bringing words like “hyperbole” into the discussion is again flawed argument.

The explanation/proposal so far doesn’t make sense and lacks even internally consistent motivation.

The proposal for an LTS seems to be:

1. Someone wants a consistent/reliable platform to build against with guarantees that their software won’t break
2. They don’t want to use new Editions because??? Why???
3. They want to stick to whatever version they originally built with, but, they want security/bug fixes to that version over a long time period…Why? So they don’t have unexpected changes/bugs in their software? So they don’t have to do as thorough of testing?

I have software that builds and passes all my tests. I upgrade to a new Edition. My software, without changes is guaranteed (sans bugs) to build and be equivalent (sans bugs) without me having to change my software. How is that different from me building with a new “micro/security/bug-fix version” of the compiler? What does the latter offer me that the former does not? I haven’t seen anywhere it articulated what the benefit is (beyond a lot of “Maybes”). That is why I say the idea/proposal lacks even internally consistent logic.

For #1, the Edition system accomplishes that. For #2, I can’t even counter-argument because no reason has been provided. For #3, just doesn’t offer anything of value beyond using a new Edition. In fact, it offers less. It requires back-porting (which can and will introduce additional/different bugs over time) of security/bug-fixes from the latest Editions with the potential of requiring odd work-arounds to make whatever patches are necessary compatible with the old code base. This seems like a higher risk rather than a lower risk. If the idea is that less testing/verification of the build is required, that is just not consistent with the idea that any change may introduce a bug/regression at any time. The way you avoid that, is through comprehensive, unit, regression, and integration tests. Not by gambling that somehow an LTS release with back-ported security/bug fixes is less of a risk than the latest/greatest compiler Edition.

[H2CO3]

They don’t want to use new Editions because??? Why???

Personally, I strongly dislike many additions and changes to Rust which are expected to land in the 2018 edition, and I feel they are causing it to steadily move away from the simple, orthogonal, systems programming oriented original path towards a model more akin to modern scripting languages which are not to be named here, with the language team preferring the addition of several infrequently necessary convenience features over keeping the core small, thus making the language bloated, unnecessarily complicated, and sometimes uglier, and so inevitably introducing misunderstandings and in turn bugs. Therefore, I would very much prefer sticking with the 2015 edition even in my new projects.

[gbutler]

Again, I think you misunderstand “Editions”. You will be able to build your 2015 Edition Code with the 2018 Edition Compiler without change and without having to use any of the new features AND you will be able to inter-operate seemlessly with both 2015 Edition Crates and 2018 Edition Crates all built with the 2018 Edition compiler. So, again, where is the benefit of an LTS? I’m just not seeing it. (Seriously, I’m not trying to be a prick or anything like that.)

[H2CO3]

Again, I think you misunderstand “Editions”.

No, I don’t think so.

You will be able to build your 2015 Edition Code with the 2018 Edition Compiler without change and without having to use any of the new features

Yes, I know this. However, once I start using the new edition, coworkers, contributors, etc. will inevitably start using new features / asking me to use them. So realistically, the “you don’t have to” argument only works if I am the sole contributor to a crate. This is more of a cultural rather than a technical issue, but it’s still important.

[gbutler]

However, once I start using the new edition, coworkers, contributors, etc. will inevitably start using new features / asking me to use them.

Ah…OK, I see where you are coming from, but, I just don’t think that is a reasonable stance. That goes against the “Stability without Stagnation” mantra that is a hallmark feature of the Rust ecosystem. You are saying you want “Stability with Stagnation, with security/bug-fixes” and you want that to be called an LTS. That just doesn’t seem like a reasonable thing to expect of the community (IMHO). I can see contracting with a commercial provider to provide that guarantee against some chosen Edition of Rust (and I’m sure as Rust becomes popular, lots of providers will be happy to provide, contract, and bill you for that service), but, it just doesn’t seem like a reasonable thing to expect or demand from the community at-large.

[gavento]

Do GCC or Clang provide LTS releases of their compilers?

Exactly my thought – people here mostly talk about individual C++ standards and their support, but not about compiler versions themselves. For example, the GCC development plan keeps updating two major versions at any time. There may be updates to older compilers but I am not sure if any patches to older releases are by the GCC team or package maintainers.

So asking anybody with a better insight into the GCC/Clang development: What is the status of long-term maintained releases, and how often is it necessary to avoid updating to a new major GCC version to avoid some breakage? And what is usually the breakage cause? (E.g. your project code, code of third-party libraries, binary-only modules and ABIs, or perhaps outdated libraries required by the compiler in the linux distros?)

[cuviper]

Do GCC or Clang provide LTS releases of their compilers?

GCC releases major versions once a year, and generally issues updates for the past two.

LLVM (w/ Clang) releases major versions twice a year, and usually only issues updates for the latest. I think they’re planning a spectre/meltdown update for LLVM 5 though, as an exception.

Compared to Rust every 6 weeks, even their regular releases look like LTS!

[cuviper]

There may be updates to older compilers but I am not sure if any patches to older releases are by the GCC team or package maintainers.

The GCC team and package maintainers are overlapping sets.

[gbutler]

The GCC team and package maintainers are overlapping sets

Yes, but, when a particular developer applies/back-ports changes/bug-fixes/security-fixes to an older compiler version (i.e. not the current/latest), would you consider that they have their “Package Maintainer” or “GCC Contributor” hat on? Perhaps, more importantly, which hat do they think they are wearing at that point?

[cuviper]

That’s still a blurry line – changes could be motivated by their package needs or something external. Why do you think it’s important to distinguish their role?

[gbutler]

Why do you think it’s important to distinguish their role?

If I’m the package maintainer for (for example) Debian Rust packages, but, I’m also a regular contributor to upstream development of Rust and Rust compilers, when I am performing my duties as a Package Maintainer, I have a certain set of goals and motivations (and responsibilities); however, when I’m contributing to development of the Rust compiler and ecosystem, I have a different set of goals and motivations (and responsibilities). So, if I were to back-port bug/security fixes from the current Rust development stream to an older (let’s call it LTS) version, under which set of goals, motivations, and responsibilities am I conducting that activity? Similarly, if I am adding new features to the language or fixing bugs or security issues in the current release train of Rust which “Hat” am I wearing?

Just because I do both things doesn’t have anything to do with which group is ultimately best responsible for a particular activity. This tends to make the fact that you pointed out that the two groups overlap somewhat irrelevant to the discussion, iif it is clear that the various activities naturally fall into one or the other roles (hats).

I (and probably many others) would argue that there is a clear distinction in these roles and responsibilities and that conflating them isn’t useful in determining if having a Rust Community Maintained and Sponsored LTS Release is appropriate. In fact, I would argue that identifying under which role (hat) these activities are normally conducted pretty much makes the answer apparent.

I would be willing to bet that most, when pressed, to clarify under which role they were operating for the various activities would say:

• Package Maintainer: back-porting bug-fixes/security-fixes to older versions/LTS releases
• Compiler Contributor: New features/bug-fixes/security-fixes to the current compiler development (though there may be multiple branches considered “current”)

If that is true, then the argument for a Rust Community Sponsored/Supported LTS, as opposed to a distribution package maintainer and/or commercially supported, release is fairly weak (IMHO).

[gbutler]

So realistically, the “you don’t have to” argument only works if I am the sole contributor to a crate

I don’t agree with that. If you are the crate owner, you simply set the Edition version in your cargo.toml and forbid PR’s that change it. If you aren’t the create owner, then, well…when in Rome.

[cuviper]

It may well be that the “Rust Community Sponsored/Supported LTS” would be primarily driven by packagers, but it’s still valuable for such people to collaborate, rather than reinventing the same efforts in their own silos.

[gbutler]

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]

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]

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]

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.

[Manishearth]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.