[RFC #TBD] Rename the unstable branches/channels

[K900]

Users often interpret Nixpkgs "unstable" as "contains bugs", not the intended meaning of "can have breaking changes".

To avoid this confusion, we should rename the "unstable" branch to something that doesn't have those connotations.

This is an early RFC, intended to gauge consensus and identify possible technical issues. Please refrain from actual naming discussion (if you have a name suggestion, DM me on Matrix - I'm collecting those in advance).

Rendered

[FRidh]

I think we first need to find agreement on what it is actually meant for. Some see it as the development branch leading to a stable release, others see it as the branch for a rolling distro.

[K900]

I think we first need to find agreement on what it is actually meant for. Some see it as the development branch leading to a stable release, others see it as the branch for a rolling distro.

I think that even if treated as a "development" branch, the amount of testing we do in Hydra produces a result that's extremely usable as a rolling release distro. I don't actually remember unstable being outright broken basically ever?

[FRidh]

I think that even if treated as a "development" branch, the amount of testing we do in Hydra produces a result that's extremely usable as a rolling release distro. I don't actually remember unstable being outright broken basically ever?

I'd say this is about managing people's expectations. Given we have the release schedule along with restrictions of what is mergable in certain periods and what not, I'd argue the current unstable is primarily our development branch. People can use it as a rolling release, but as long as there is the acknowledgement that it can be breaking in the period that larger changes are allowed (as you've mentioned in the OP).

[7c6f434c]

What is our reference point for «unstable» in distributions? Debian unstable which is also more or less a rolling release distro in practice?

[K900]

What is our reference point for «unstable» in distributions? Debian unstable which is also more or less a rolling release distro in practice?

I don't think one exists, really. Debian's "unstable" is also mostly named that because it's API unstable, not "has bugs" unstable.

[K900]

I think that even if treated as a "development" branch, the amount of testing we do in Hydra produces a result that's extremely usable as a rolling release distro. I don't actually remember unstable being outright broken basically ever?

I'd say this is about managing people's expectations. Given we have the release schedule along with restrictions of what is mergable in certain periods and what not, I'd argue the current unstable is primarily our development branch. People can use it as a rolling release, but as long as there is the acknowledgement that it can be breaking in the period that larger changes are allowed (as you've mentioned in the OP).

I think we should be making a distinction here. Breaking API changes are always allowed on unstable. Introducing major bugs should not be allowed anywhere, and if we get one, that really just means we need more tests.

[7c6f434c]

Introducing major bugs should not be allowed anywhere

No, it's fine in staging. (Which corresponds to Debian experimental, I guess)

[K900]

No, it's fine in staging. (Which corresponds to Debian experimental, I guess)

I mean major bugs that make their way to a channel. It's obviously unavoidable that we will have major bugs in any branch, the goal is to make the tests catch them before they impact users.

[7c6f434c]

Ah, as your title is about branches… (and with staging, I did mean intentionally introducing bugs to fix them step by step)

[K900]

Actually, thanks, the title should explicitly mention channels, as they are not quite the same as branches.

[kevincox]

In my opinion the unstable term is accurate enough. (Worst case we are under promising and over delivering.) I think it is unlikely that a new name will be worth the effort and confusion a rename brings.

[lheckemann]

One thing we don't have which we would need at least for me to feel comfortable with a less scary name like "rolling" is continuous management of release notes. Currently, we have the release notes entry as one of the checkboxes in the PR template, but I don't think all reviewers pay attention to it, and only ahead of each release do we actually have a systematic effort around trying to get the release notes into an accurate and reasonably complete state.

[kevincox]

I think we should pick a name as part of the RFC. It is hard to evaluate the benefits a better name brings without knowing what the name is. Therefore we can only evaluate the downsides without evaluating the upsides. So unfortunately we have to assume that this RFC has negative value. I don't feel comfortable accepting an RFC with just a "it will be great, trust us" promise for the advantages.

[7c6f434c]

the goal is to make the tests catch them before they impact users

Hm. If the reasoning relies on tests, nixpkgs-unstable does not run most of the NixOS tests, and duplication of functionality arguments prevent us from having end-to-end non-NixOS tests for many packages, does this mean that renaming nixpkgs-unstable is not justified by this argument (the justification is specific to nixos-unstable)?

[7c6f434c]

I don't think one exists, really. Debian's "unstable" is also mostly named that because it's API unstable, not "has bugs" unstable.

OK, what major software project uses «unstable» to determine something that is much buggier than NixOS unstable (which is not that polished even in the things we control, and also we sometimes fail at mind-reading upstreams)?

I just think that if we are in line with the terms of art, the renaming is not worth the hassle. Our learning curve has an inherent part, and some general prerequisites, if someone is scared away by «unstable», maybe they are better off on the release version? We are not Debian, our releases are aiming to package stuff less than a year old.

[suhr]

Users often interpret Nixpkgs "unstable" as "contains bugs", not the intended meaning of "can have breaking changes".

Are you implying that Nixpkgs does not contains bugs?

[K900]

I can now see that the RFC was based on my mistaken assumption that there is already widespread consensus on what the reliability guarantees of nix{os,pkgs}-unstable are supposed to be. I am going to draft this RFC for now, and maybe try to organize some sort of effort on defining those first.

[raboof]

what major software project uses «unstable» to determine something that is much buggier than NixOS unstable (which is not that polished even in the things we control, and also we sometimes fail at mind-reading upstreams)?

My impression is NixOS unstable seems more stable than Debian unstable, but that might be n=1 anecdotal.

It might be relevant to take into account "how scary it is to run unstable": because of easy rollbacks, it's much less scary to run NixOS unstable compared to many other unstable things. For that reason something "less scary" like nixos-rolling would be nice IMO, though we'd have to clearly document what we promise by that (both so people know what to expect and contributors know what standards to apply)

[samueldr]

My impression is NixOS unstable seems more stable than Debian unstable, but that might be n=1 anecdotal.

It might be relevant to take into account "how scary it is to run unstable": because of easy rollbacks, it's much less scary to run NixOS unstable compared to many other unstable things. For that reason something "less scary" like nixos-rolling would be nice IMO, though we'd have to clearly document what we promise by that (both so people know what to expect and contributors know what standards to apply)

Expanding on that, Arch Linux only is ambiantly "rolling" (testing excluded), and is prone to more breakage and maintenance (if you don't read the news) than NixOS unstable, so my judgement is rolling is more appropriate for NixOS since it's less breaking than the most popular(?) rolling distribution.

We could even be cute (maybe don't) and call it walking, or sprinting, or running (yes it runs!), since we're not tumbl(eweed?)ing down uncontrollably rolling!

[samueldr]

Expanding even further:

Other than upstream new version breakage/behaviour changes, the same guarantees of software stability and boot-readyness exists for "stable" than "unstable", at branch-off time, the same test suite checks the channel can go forward. So for all intents and purposes, "unstable" is just as much "ready to run" (running?) than stable until new tests makes it even more guaranteed to continue being ready.

In other words, the backports policy makes non-major upgrades just as breaking in "stable" than "unstable".

[raboof]

Other than upstream new version breakage/behaviour changes, the same guarantees of software stability and boot-readyness exists for "stable" than "unstable", at branch-off time, the same test suite checks the channel can go forward. So for all intents and purposes, "unstable" is just as much "ready to run" (running?) than stable until new tests makes it even more guaranteed to continue being ready.

At the risk of going offtopic, that 'new version breakage' might be significant though: while indeed the same test suites are applied, for example the "zero hydra failures" process hopefully makes the stable channels actually more stable than some points in time on unstable. Also processes like https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/python.section.md#cpython-update-schedule-python-cpython-update-schedule (IIRC we have something similar for the major desktop environments?) are timed so that there might be some breakage to expect on unstable, which should have some time to stabilize before it makes it into a stable channel. I think that's sensible (and doesn't stop me from using unstable even for environments that I don't want to break :) )

[samueldr]

Note that I agree with what you said, @raboof, but also, that describes the usual rolling release guarantees in practice!

[KFearsoff]

We could even be cute (maybe don't) and call it walking, or sprinting, or running (yes it runs!), since we're not tumbl(eweed?)ing down uncontrollably rolling!

Or we could do "NixOS blizzard", "NixOS snowfall" or something like that to have a play on the snowflake thingie :)

[edolstra]

I think "unstable" is fine, since both interpretations ("can have bugs/regressions" and "can break interfaces") apply to our master branch. (Of course the "stable" branches can have regressions too, but our backport policy tries to minimize the chance of that happening.)

The (mostly speculative) advantages of other names are vastly outweighed by the huge pain of a rename. Renames of this nature are almost never worth it. Names are interfaces and we shouldn't break them unless there is a really compelling reason.

When introducing people to Nix and NixOS, the very first question that often arises is "why are we using unstable?".

That's a good question, since most people shouldn't be using unstable.

[KFearsoff]

I think "unstable" is fine, since both interpretations ("can have bugs/regressions" and "can break interfaces") apply to our master branch.

When people say a software is "unstable", they really mean that it crashes, or contains a lot of bugs, or has flaky and non-reproducible bugs, or is just of poor quality. I think only the software people mean "often changes" by "unstable".

Renames of this nature are almost never worth it. Names are interfaces and we shouldn't break them unless there is a really compelling reason.

Could we consider renaming stable? Technically, we don't have "stable": we have a release number (and a release name technically, but I don't think anyone ever refers by it specifically?). If we could come up with a general term for releases that emphasizes their set-in-stoneness, I think it help people understand the "unstable" while not breaking the interface. Some of the names I immediately think of (and those seem pretty bad lol) are: "Snapshot", "Freeze", "LTS", "Branched", "Static", "Traditional".

That's a good question, since most people shouldn't be using unstable.

Why?

I'm genuinely interested, because the most popular desktop OS by far is "unstable" (Windows), one of the most popular Linux distros is "unstable" Arch Linux, and then there's SteamOS which is getting traction (and is also "unstable"). Ubuntu also has moved to "unstable" direction with their snaps (which are a hack to bypass dependency hell of introducing new software to older system, and contain auto-update). Damn, a lot of software auto-updates in general: Chrome, Discord, VSCode, etc.

I think focusing on "stable" releases is a long-lived tradition of Linux people that does more harm than good, to be honest. People are used to all of the stuff updating quite often (because they used Windows for a long time, for example), and breaking changes too. People don't quite like it, but not updating your browser or messaging apps (that would gladly lock you out if you don't update for a while) or stuff like Steam or Lutris is impossible. And providing new versions of all of that stuff together with "stable" software is challenging due to a lot of factors.

I think NixOS really excels at the fact that it is a rolling-release distro that rarely breaks (and when it does, you just rollback). I think there's a decent portion of people who use Arch Linux and hate themselves for having to fix the system very often, and people who use Ubuntu/Debian and hate themselves for having to use Flatpaks/Appimages/Snaps to use critical software like browsers and messengers with a modern version (and not a version that was last in use one year ago).

[K900]

Going to close this for now because I don't really have the brain juice to work on the follow-up. Sorry everyone :(

[vcunat]

People don't quite like it, but not updating your browser or messaging apps (that would gladly lock you out if you don't update for a while) or stuff like Steam or Lutris is impossible.

That's why we keep updating such packages even on "stable" releases ;-)

EDIT: as for "more harm than good", I'd agree with 10-year support but our half-year cycles are very short. Probably still too short for people who "don't like updating often".

[Shados]

@KFearsoff

I'm genuinely interested, because the most popular desktop OS by far is "unstable" (Windows), one of the most popular Linux distros is "unstable" Arch Linux, and then there's SteamOS which is getting traction (and is also "unstable"). Ubuntu also has moved to "unstable" direction with their snaps (which are a hack to bypass dependency hell of introducing new software to older system, and contain auto-update). Damn, a lot of software auto-updates in general: Chrome, Discord, VSCode, etc.

I think focusing on "stable" releases is a long-lived tradition of Linux people that does more harm than good, to be honest. People are used to all of the stuff updating quite often (because they used Windows for a long time, for example), and breaking changes too.

A few things:

• You appear to be conflating "auto-updates" with "unstable releases", but the two are entirely orthogonal. You can auto-update something against a stable release channel, or pin something to a specific unstable release for a long period of time. A distro stable release channel avoids making breaking changes, but that doesn't mean it avoids all changes, package updates, security patches, etc.
• Windows releases are at least not "unstable" in the "includes breaking API changes" sense; MS has historically gone to quite significant lengths to maintain backwards-compatibility with older software (although it seems like this may be changing with W11). They do more often break things for the user / have bugs, but that's the other sense of the word "unstable".
• SteamOS runs the vast majority of its software (games and anything else managed through Steam) within a Steam Linux Runtime, which are containerised Linux images, each bundling a known set of libraries from a specific distro/version, all of which is done specifically to provide a stable ABI & API for games to run against. Again, this a system that goes to significant lengths to avoid breaking API changes for its apps (despite being based on Arch Linux).
• Arch Linux is the only given example that actually is a meaningfully unstable release. It also is fairly popular, at least within the desktop enthusiast and gaming niches, but I don't see how its popularity makes an argument for recommending new NixOS users run on the unstable channel. There's probably an argument to recommend the unstable channel for people moving from Arch to NixOS, though?

People don't quite like it, but not updating your browser or messaging apps (that would gladly lock you out if you don't update for a while) or stuff like Steam or Lutris is impossible. And providing new versions of all of that stuff together with "stable" software is challenging due to a lot of factors.

As vcunat pointed out, software that needs to be updated to continue to work (or be secure, etc.) does still get updated on the stable releases.

I think NixOS really excels at the fact that it is a rolling-release distro that rarely breaks (and when it does, you just rollback). I think there's a decent portion of people who use Arch Linux and hate themselves for having to fix the system very often, and people who use Ubuntu/Debian and hate themselves for having to use Flatpaks/Appimages/Snaps to use critical software like browsers and messengers with a modern version (and not a version that was last in use one year ago).

It's quite trivial to run NixOS on a stable channel, and still install a few packages from unstable, which is likely the better approach for the latter group of people, assuming said software isn't updated enough on the stable channel to begin with...

Also, not really NixOS-related, bu it's amusing to me that you mention Flatpaks here: Flatpak releases of application updates are often months or years behind distro releases, particularly when it comes to security patches in dependencies. Even for the subset of Flatpak applications that get frequently updated, the runtimes they're based on don't get updated nearly as often. The core freedesktop runtime, for example, has stable release channels on a yearly cycle and a 2-year support period (I think?), it's not a rolling-release system.

[lheckemann]

That's a good question, since most people shouldn't be using unstable.

Aliasing nixpkgs to the nixpkgs-unstable branch in the flake registry seems like a strange choice then.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-11-09-documentation-team-meeting-notes-93/35244/1