(This is not an official Nix RFC. We think this decision falls into the responsibility of the Haskell maintainers team, nevertheless we are literally requesting comments.)
Context
Currently nixpkgs has no rules for which GHC versions it supports. Versions were just dropped whenever it felt sensible. At the moment we offer source-compiled GHC versions from 8.10 to 9.12 + HEAD. The default GHC version is 9.8, which we inherit from Stackage LTS.
Non-default GHC versions in nixpkgs are of limited usability. Newer versions are relatively important and appear to be frequently used as technology preview and in preparation for them to become default. Generally non-default GHC versions have limited test coverage and are primarily useful to use with cabal and stack for development. However, for that they are moderately important because there are no alternative install methods for GHCs on NixOS.
Motivation
The current situation has mostly been fine, because keeping old GHC versions around is not very maintenance heavy, but it has a cost in CI and maintainer time. Especially, old GHC versions are some of the primary consumers of old LLVM versions in nixpkgs which also puts strain on more than the Haskell maintainers. Having a clear policy increases transparency and predictability for all people involved.
Suggested Policy
We suggest the following policy:
Major GHC versions
- We aim that the oldest included GHC version in nixpkgs is the minimum of
- 2 major versions before our default ghc version (i.e. Stackage LTS). (This is basically the same policy as HLS.)
- the currently recommended ghcup version
- GHC versions might need to be kept longer if there are in-tree consumers of those versions. We will coordinate with the maintainers of those dependencies to find a way forward.
- Deprecations will be announced in the release notes of NixOS stable releases before affecting the next release. (Potentially only tentative if removal is not sure.)
Minor GHC versions
- For every major version we have a default minor version. When new minor versions get released and added the default version will update to the new minor version as soon as viable without breakage.
- Older minor versions for a supported major version will only be kept around if they are the last supported GHC version of a major Stackage LTS release.
Potential Alternative to 2.
- Older minor version for a supported major version will only be kept around if they are the last supported GHC version of a minor Stackage LTS release.
Rationale
Re: Major Versions
- It seems likely that this policy gives all consumers enough time to keep up with the default versions.
- For a modern programming language, language server support is important, thus supporting GHC versions without HLS support is of limited use.
- ghcup puts emphasize on giving consistent support for the same GHC versions across all plattforms. Since ghcup currently does not support NixOS we should do our part in that goal. (This would e.g. be a good GHC version to choose for consistent support amongst students in a Haskell course.)
- Older GHC versions via Nix are still available via older nixpkgs versions or haskell.nix.
Re: Minor Versions
- The nix integration of stack currently takes the exact matching minor version from nixpkgs. The “Alternative to 2” rule is basically what we are currently doing. With the new policy users which pin an exact minor version of a stackage snapshot will need to either use it with a newer minor version of ghc (which is very likely to not cause problems) or update to a newer minor release of their stackage snapshot (which is also very likely to not cause problems). This is a slight inconvenience for stack users on nixos but will significantly reduce the number of CI jobs, which cost build time and can fail spuriously.
Implications
- At the time of writing our default is 9.8, 2 major versions before that is 9.4. The current recommended version by ghcup is 9.6.
- This means that after branching off NixOS 25.05 we would drop support for 8.10, 9.0 and 9.2, which would not be present in 25.11.
- The old GHCJS will be dropped The last ghc version to which the old GHCJS was updated was GHC 8.10. Thus the old GHCJS will be dropped. There is already limited support for the new js backend in nixpkgs. We suspect that this removal will not cause problems because the known active consumers of old GHCJS already rely on severely backpinned nixpkgs versions and are planning to jump to the new backend.
- The removal of GHC 8.10 is conditional on finding a solution for a few packages, including some from the elm ecosystem, which currently rely on that version.
Request For Comments
Previously we have been very defensive about dropping GHC versions because it is very hard to tell who is using our GHCs and for what.
Thus we ask the whole community to widely share this post and to comment here if you currently rely on a current nixpkgs for using one of the GHC or GHCJS versions nominated for removal.
Additional information which is interesting to us:
- Why are you on these old versions and what would need to happen/are you waiting for to update?
- If you rely on the old versions, do you use the LLVM backend? This is for example true if you use aarch64 with GHC < 9.2. (One alternative proposal would be to continue support but drop the LLVM backend, limiting plattform support.)
- If possible, a bit about your context, e.g. is this a business setting, education or private use. (All use cases are important to us, but it’s interesting nonetheless.)
Thank you for reading this far. Have a nice day.