TLDR: We’ll release Nix 2.4 soon and then move to a 6-weekly release schedule.
The last major Nix release, 2.3, came out in September 2019. Since then, there has been a huge amount of work on the Nix master branch, including major improvements to the new command line interface and new experimental features such as flakes, the content-addressable Nix store, and recursive Nix. This forces more and more users to use unstable Nix releases. So a new release is very much overdue.
However, the master branch is not quite in a releasable state yet. Therefore we’ll stabilize master in the next few weeks and then cut a 2.4 release. If you want to help out, please have a look at the 2.4 milestone on GitHub.
Going forward, we want to avoid having such long gaps between releases, since it’s bad for both contributors and users that there is an unbounded amount of time before a new feature shows up in a stable release. The thing that has historically caused long gaps between Nix releases is new experimental features landing in master that we weren’t quite sure about, and doing a new release meant having to support these features indefinitely. However, Nix 2.4 introduces an
experimental-features setting that enables us to add such features in a way that they can be changed or removed, while still getting feedback from adventurous users. So long as experimental features don’t cause breakage in stable features, it’s fine to merge them into master and make a new release.
Therefore, after the Nix 2.4 release, we’ll switch to a 6-weekly release schedule, meaning that we’ll cut a new release from the master branch every 6 weeks. (The 6-week interval may be changed in the future if it turns out to be too long or short.)
Releasing regularly means that we have to keep the master branch in a releasable state at all times. For contributors, this means that PRs with user-visible changes (such as new features) should update the release notes.
One open question is what versioning scheme to use. For now we can stick with the current scheme (i.e. only bumping the major version if there are incompatible changes or major non-experimental new features), but in the future we could switch to date-based versions (e.g. Nix 21.07).
Currently the Nix project doesn’t have a clear roadmap. Roadmaps are hard to make because they depend on what people are willing and able to work on, which is not always easy to predict. However, it’s still useful to have a roadmap to provide a “north star” for the community. So with the appropriate caveats, here is a rough roadmap for the next year or so:
- Flakes (experimental).
nixCLI (still marked as experimental, but we’ll try to avoid major changes after this release).
- Content-addressable Nix store (CAS) (experimental).
- 2.5, …
- 6-weekly releases as needed.
- Flakes and
nixCLI declared stable.
- Flakes and
- CAS semantics and interfaces declared stable.
This is really just a starting point for a roadmap. Other items that could be added in the future (depending on what people are interested on working on) are UX improvements, rootless Nix, Nix as a build tool, Nix for HPC, Nix modules and supporting new configuration languages such as Nickel or TOML.
Any comments you may have, especially ideas about what you consider important for the Nix roadmap, are very welcome!