“Long term support” Unixes and versions of software in them

In a comment on my entry about how Firefox versions are relatively tightly tied to Rust versions and how this affects LTS Unixes, Tom said, in part:

[...] But, if Ubuntu LTS is going to have a version of rust that is relevant to users (rather than just as a build dependency), they should really package a up-to-date version of rust as well, since it has the same support period as does Firefox.

The problem that all Unix distributions face sooner or later is that the people using them generally want the platonic ideal version of semantic versioning minor releases, namely updates that only fix bugs and improve things and never introduce backward compatibility problems or undesired changes. Apart from other problems with semantic versioning, the reality of life is that almost no modern open source project works this way for very long, including languages. Rust has stopped accepting cargo.toml files that it used to (cf), Go has significantly changed how the toolchain worked (cf), and even C compilers have broken compilation of existing things by adding new warnings (cf).

(And languages are often the conservative things here. Many things with GUIs undergo much more change much faster. Firefox and Chrome are arguably two poster children for this.)

The state of modern software is that almost nothing holds to the ideal of semantic versioning minor releases over the span of a few years, much less the five years that is the common duration for modern "LTS" releases (although they may or may not make this clear in their version numbers). This is true for the latest releases of software, and it's also almost always true for the supported versions, because very few software projects support old releases for multiple years, especially three or four or five years. The consequence is that whether you keep up with the latest versions or just the latest supported version, sooner or later you'll have to install an update that isn't fully backward compatible. Some of the time, this will make people unhappy (although some of the time the change will be in an area that they don't care about).

(Note that not all projects follow semantic versioning in their version and release numbers. I think both Rust and Go would say that they don't, for example. And semantic versioning is ultimately a social understanding anyway.)

This leaves Unix distributions with three choices. They can not pretend to be stable over the long term, they can be stable over the long term with old software versions, or they can be "stable" over the long term with newer versions of eg Rust with the hopes that this won't introduce too many changes that upset people. Most Linux distributions pick either the first or the second, with as little of the third as they can get away with. If nothing else, this leaves people with a relatively clear choice; you can accept churn with the benefit of being relatively current, or you can accept stale software in order to get long periods of low or no churn.

from Hacker News https://ift.tt/MlTKdPx