mirror of
https://github.com/privatevoid-net/nix-super.git
synced 2024-11-22 14:06:16 +02:00
Update the release cycle
- Align the “frequent” release cycle with the calendar - The 6-month release cycle is hard to keep track of. A monthly release will make it much easier to remember the release date. - Officialise the support for a stable version maintained for as long as NixOS stable - This is already the case in practice, it just happens that the “stable” Nixpkgs version is whichever version was deemed stable-enough at the time of the NixOS release. Officialise that by cutting a new major release alongside each NixOS one. Note that this breaks whatever semver compatibility Nix might pretend to have, but I don't think it makes sense any way.
This commit is contained in:
parent
a223280664
commit
c13a31f639
2 changed files with 13 additions and 10 deletions
|
@ -119,7 +119,7 @@
|
||||||
- [Experimental Features](contributing/experimental-features.md)
|
- [Experimental Features](contributing/experimental-features.md)
|
||||||
- [CLI guideline](contributing/cli-guideline.md)
|
- [CLI guideline](contributing/cli-guideline.md)
|
||||||
- [C++ style guide](contributing/cxx.md)
|
- [C++ style guide](contributing/cxx.md)
|
||||||
- [Release Notes](release-notes/index.md)
|
- [Releases](release-notes/index.md)
|
||||||
{{#include ./SUMMARY-rl-next.md}}
|
{{#include ./SUMMARY-rl-next.md}}
|
||||||
- [Release 2.21 (2024-03-11)](release-notes/rl-2.21.md)
|
- [Release 2.21 (2024-03-11)](release-notes/rl-2.21.md)
|
||||||
- [Release 2.20 (2024-01-29)](release-notes/rl-2.20.md)
|
- [Release 2.20 (2024-01-29)](release-notes/rl-2.20.md)
|
||||||
|
|
|
@ -1,12 +1,15 @@
|
||||||
# Nix Release Notes
|
# Nix Release Notes
|
||||||
|
|
||||||
Nix has a release cycle of roughly 6 weeks.
|
The Nix release cycle is calendar-based as follows:
|
||||||
|
|
||||||
|
- A new minor version (`XX.YY+1.0`) is published every month and supported for two months;
|
||||||
|
- A new major version (`XX+1.1.0`) is published twice a year, in April and October, and supported for eight months.
|
||||||
|
|
||||||
|
The rationale behind that cycle is that
|
||||||
|
- Minor versions stay close to master and bring early access to new features for the user who need them;
|
||||||
|
- Major versions are aligned with the NixOS releases (released one month before NixOS and supported for as long at it).
|
||||||
|
|
||||||
|
Bugfixes and security issues are backported to every supported version.
|
||||||
|
Patch releases are published as needed.
|
||||||
|
|
||||||
Notable changes and additions are announced in the release notes for each version.
|
Notable changes and additions are announced in the release notes for each version.
|
||||||
|
|
||||||
Bugfixes can be backported on request to previous Nix releases.
|
|
||||||
We typically backport only as far back as the Nix version used in the latest NixOS release, which is announced in the [NixOS release notes](https://nixos.org/manual/nixos/stable/release-notes.html#ch-release-notes).
|
|
||||||
|
|
||||||
Backports never skip releases.
|
|
||||||
If a feature is backported to version `x.y`, it must also be available in version `x.(y+1)`.
|
|
||||||
This ensures that upgrading from an older version with backports is still safe and no backported functionality will go missing.
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue