From 8a85163866c56db42a9c6ef682426782d01b9ed2 Mon Sep 17 00:00:00 2001 From: Eelco Dolstra Date: Thu, 23 Sep 2021 12:41:18 +0200 Subject: [PATCH 1/5] Nix release schedule --- rfcs/0106-nix-release-schedule.md | 91 +++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 rfcs/0106-nix-release-schedule.md diff --git a/rfcs/0106-nix-release-schedule.md b/rfcs/0106-nix-release-schedule.md new file mode 100644 index 000000000..f7c828153 --- /dev/null +++ b/rfcs/0106-nix-release-schedule.md @@ -0,0 +1,91 @@ +--- +feature: Nix release schedule +start-date: 2021-09-23 +author: Eelco Dolstra +co-authors: (find a buddy later to help out with the RFC) +shepherd-team: (names, to be nominated and accepted by RFC steering committee) +shepherd-leader: (name to be appointed by RFC steering committee) +related-issues: N/A +--- + +# Summary +[summary]: #summary + +Do a new Nix release every 6 weeks. + +# Motivation +[motivation]: #motivation + +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 many users to use unstable Nix +releases, which is undesirable. + +In the future, we should 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 include them in a new release. + +# Detailed design +[design]: #detailed-design + +* We do a new Nix release every 6 weeks. The release process is + already almost entirely automated so this is pretty easy. + +* The master branch should be kept in a releasable state at all times. + +* PRs should include release notes, if applicable. (Currently trawling + through the history to dig up interesting stuff for the release + notes is the most work in making a new release.) + +# Drawbacks +[drawbacks]: #drawbacks + +Infrequent releases give more stability to users. Users of Nix-stable +have been blissfully isolated from all the code churn on master for +the last two years. + +# Alternatives +[alternatives]: #alternatives + +Stick to the current release-when-it's-ready non-schedule. + +# Unresolved questions +[unresolved]: #unresolved-questions + +* Should we still do maintenance releases (like 2.3.x)? Should there + be a long-term stability release (like 2.3 is now, de facto)? + Probably we should at least provide bug fixes for whatever Nix + release is used by the latest NixOS release. + +* Is 6 weeks the ideal interval between releases? It seems to work + well for Rust. + +* Should we keep using the current versioning scheme? 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). + +# Previous work + +[RFC 0009](#9) proposed a rapid release policy where releases can be +done at any time (e.g. on request) rather than on a fixed schedule. It +wasn't feasible at the time because we didn't have a notion of +experimental features, so we had to give such features some time to +stabilize before doing a new release. + +# Future work +[future]: #future-work + +N/A From 00ef14f9f270a6f67f95ea20816feac21cc61027 Mon Sep 17 00:00:00 2001 From: Eelco Dolstra Date: Thu, 23 Sep 2021 16:31:18 +0200 Subject: [PATCH 2/5] Fix link --- rfcs/0106-nix-release-schedule.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/rfcs/0106-nix-release-schedule.md b/rfcs/0106-nix-release-schedule.md index f7c828153..859f3ff83 100644 --- a/rfcs/0106-nix-release-schedule.md +++ b/rfcs/0106-nix-release-schedule.md @@ -79,11 +79,12 @@ Stick to the current release-when-it's-ready non-schedule. # Previous work -[RFC 0009](#9) proposed a rapid release policy where releases can be -done at any time (e.g. on request) rather than on a fixed schedule. It -wasn't feasible at the time because we didn't have a notion of -experimental features, so we had to give such features some time to -stabilize before doing a new release. +[RFC 0009](https://github.com/NixOS/rfcs/pull/9) proposed a rapid +release policy where releases can be done at any time (e.g. on +request) rather than on a fixed schedule. It wasn't feasible at the +time because we didn't have a notion of experimental features, so we +had to give such features some time to stabilize before doing a new +release. # Future work [future]: #future-work From c8e84c22025b3b55676dbedddba38778ec213d94 Mon Sep 17 00:00:00 2001 From: Eelco Dolstra Date: Wed, 1 Dec 2021 15:21:28 +0100 Subject: [PATCH 3/5] Update rfcs/0106-nix-release-schedule.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Théophane Hufschmitt --- rfcs/0106-nix-release-schedule.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0106-nix-release-schedule.md b/rfcs/0106-nix-release-schedule.md index 859f3ff83..5b82f0269 100644 --- a/rfcs/0106-nix-release-schedule.md +++ b/rfcs/0106-nix-release-schedule.md @@ -51,7 +51,7 @@ master and include them in a new release. # Drawbacks [drawbacks]: #drawbacks -Infrequent releases give more stability to users. Users of Nix-stable +Infrequent releases give somewhat more stability to users. Users of Nix-stable have been blissfully isolated from all the code churn on master for the last two years. From 5821e01fe156d40efd650277844523771783001a Mon Sep 17 00:00:00 2001 From: Eelco Dolstra Date: Thu, 9 Dec 2021 15:07:32 +0100 Subject: [PATCH 4/5] Add shepherds --- rfcs/0106-nix-release-schedule.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0106-nix-release-schedule.md b/rfcs/0106-nix-release-schedule.md index 5b82f0269..8405d0e48 100644 --- a/rfcs/0106-nix-release-schedule.md +++ b/rfcs/0106-nix-release-schedule.md @@ -3,8 +3,8 @@ feature: Nix release schedule start-date: 2021-09-23 author: Eelco Dolstra co-authors: (find a buddy later to help out with the RFC) -shepherd-team: (names, to be nominated and accepted by RFC steering committee) -shepherd-leader: (name to be appointed by RFC steering committee) +shepherd-team: @Ericson2314, @regnat, @Ma27, @tomberek +shepherd-leader: @tomberek related-issues: N/A --- From 6c51f5d7df72884cb2df9bef707336892171158f Mon Sep 17 00:00:00 2001 From: Eelco Dolstra Date: Wed, 15 Dec 2021 14:53:42 +0100 Subject: [PATCH 5/5] Update to reflect latest meeting --- rfcs/0106-nix-release-schedule.md | 34 ++++++++++++------------------- 1 file changed, 13 insertions(+), 21 deletions(-) diff --git a/rfcs/0106-nix-release-schedule.md b/rfcs/0106-nix-release-schedule.md index 8405d0e48..d34c17c63 100644 --- a/rfcs/0106-nix-release-schedule.md +++ b/rfcs/0106-nix-release-schedule.md @@ -39,14 +39,23 @@ master and include them in a new release. # Detailed design [design]: #detailed-design -* We do a new Nix release every 6 weeks. The release process is - already almost entirely automated so this is pretty easy. +* We do a new Nix release (named 2.5.0, 2.6.0, 3.0.0, ...) every 6 + weeks. The release process is already almost entirely automated so + this is pretty easy. -* The master branch should be kept in a releasable state at all times. +* For each major release, we create a maintenance branch (named + e.g. `2.5-maintenance`) and corresponding Hydra jobset. Patch + releases (e.g. 2.5.1) are made as needed. + +* The master branch should be kept in a releasable state at all + times. This means that the jobset + https://hydra.nixos.org/jobset/nix/master should be completely + green. * PRs should include release notes, if applicable. (Currently trawling through the history to dig up interesting stuff for the release - notes is the most work in making a new release.) + notes is the most work in making a new release.) The PR template + will be updated to reflect this. # Drawbacks [drawbacks]: #drawbacks @@ -60,23 +69,6 @@ the last two years. Stick to the current release-when-it's-ready non-schedule. -# Unresolved questions -[unresolved]: #unresolved-questions - -* Should we still do maintenance releases (like 2.3.x)? Should there - be a long-term stability release (like 2.3 is now, de facto)? - Probably we should at least provide bug fixes for whatever Nix - release is used by the latest NixOS release. - -* Is 6 weeks the ideal interval between releases? It seems to work - well for Rust. - -* Should we keep using the current versioning scheme? 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). - # Previous work [RFC 0009](https://github.com/NixOS/rfcs/pull/9) proposed a rapid