Skip to content
Get Started

Stabilities

flox is based on Nix, which in turn is based on the Nixpkgs collection maintained by the Nix Community. This repository is one of the most complete and up-to-date collections of build instructions for software in the public domain, but as a result it is constantly changing, and changes to Nixpkgs will inevitably cause some number of builds to fail over time.

To protect against such failures flox buffers changes to the underlying rolling release model by maintaining its own Nixpkgs fork at https://github.com/flox/nixpkgs with branches that track Nixpkgs at regular intervals, progressing commits through a sequence of "stabilities" over time:

  • unstable: This stability is brought into sync with the nixos-unstable branch of Nixpkgs upstream every Monday, Tuesday and Wednesday, and then remains unchanged to allow for integration testing before being merged to staging on the following Saturday.

  • staging: As described above, this stability is synced with unstable each Saturday and then remains unchanged until it is updated again on the following Saturday. Packages in staging remain unchanged for a full week to allow for more extensive integration testing before being merged to stable on the first Saturday of each month.

  • stable: As described above, this stability is synced with staging the first Saturday of the month. Since stable changes the least often, it therefore provides the most stable experience of using Nixpkgs over time, which is why it is the stability used by default for all flox commands. Of the three stabilities, it is also the last to benefit from updates and new packages over time, receiving updates between 10 days and 5 weeks after they've been first introduced to unstable.

The purpose of these stabilities is twofold. You can think of stabilities as providing control over the following:

  1. rate/timing of change: The stability dictates the rate at which new packages and package versions are introduced over time and imposes a schedule for the exact timing of changes.

  2. recency of updates: The stability provides a measure of how "bleeding edge" or current you want to be.

Note:

Stabilities provide a controlled way of introducing changes from Nixpkgs upstream, but testing the effects of these changes is still the responsibility of the developer. We recommend testing against staging regularly to be made aware of upcoming breakage with the monthly stable updates at the earliest opportunity.