Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 0106] Nix release schedule #106

Merged
merged 5 commits into from
Jan 26, 2022

Conversation

edolstra
Copy link
Member

@edolstra edolstra commented Sep 23, 2021

This RFC proposes doing new Nix releases every six weeks, as previously proposed on Discourse.

Rendered

@Mic92 Mic92 added status: open for nominations Open for shepherding team nominations and removed status: new labels Sep 23, 2021
@edolstra edolstra changed the title Nix release schedule [RFC 0106] Nix release schedule Sep 23, 2021
@tomberek
Copy link
Contributor

Nixpkgs/NixOS releases have mechanisms that encourage stability as well as ensuring it gets done. Concepts like release managers, ZHF, release channels (along with all the corresponding testing), backports policy, wiki about release process, and so forth help drive progress. I don’t have a solid idea formulated yet, but I think some analogous concept would be good to include in this RFC.

@abathur
Copy link
Member

abathur commented Sep 28, 2021

I have no strong opinions on semver vs. calver. Thoughtful semver is useful, but not so great that it'd be worth regular debates over whether a release qualifies as an x/y/z bump instead of something a script generates.

I guess I'd prefer semver if it's a decision being made within 24h of release by a small, decisive group with good heuristics/razors. If it takes longer than that, it's probably better for everyone to just automate it.

This is a little far afield, but I've daydreamed about "test-driven versioning." I can't really extoll its virtues--it's just something I vaguely intend to give a try someday--but it struck me while writing this that some of Nix's ~contracts (like store, CLI, and daemon compatibility) might make interesting candidates for test-enforced version promises.

rfcs/0106-nix-release-schedule.md Outdated Show resolved Hide resolved
[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)?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see the point of this. Ideally, the only backward-compatible changes that happen in Nix are in the interface, not the language and building mechanisms. Because of this, supporting a new Nix release in a project will likely never require large changes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dunno for the long-term releases, but I think we’ll have to do maintenance releases anyways, if only because we might have to do some bug fixes on the latest release before the end of the 6w cycle

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this is true, a lot of smaller changes don't get an experimental feature, e.g. NixOS/nix#4922. Perhaps there should be a generic experimental feature for enabling unstable minor changes such as this, so that we don't have to add an experimental feature for each?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think having a arbitrary (reasonable) number of experimental features is too much of an issue. People shouldn’t be expected to just blindly buy into them, and having each feature guarded by an experimental flag gives more flexibility to rework/abandon them.

(Anyways, I think the usage of experimental features should be refined/standardized, but that’s out of scope for this RFC)

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-release-schedule-and-roadmap/14204/18

@Ericson2314
Copy link
Member

Ericson2314 commented Oct 14, 2021

I think the most critical thing is not necessarily release branches, but upgrading. E.g. if Nixpkgs goes CA-drvs default, making sure the previous n stable Nixpkgs releases have a new enough Nix.

@lheckemann
Copy link
Member

I'd like to nominate:

  • @Ericson2314 and @regnat, major contributors to nix in the past year
  • @mweinelt, who does a lot of work keeping nixpkgs stable branches stable
  • @Ma27, who does a lot of work keeping nixpkgs stable branches stable and keeps a close eye on regressions in nixUnstable

as shepherds.

@Ericson2314
Copy link
Member

Sure!

@Ma27
Copy link
Member

Ma27 commented Oct 28, 2021

I'm certainly interested, but not sure if I have the capacity in the next time for another duty. I should have an answer to this by the beginning of next week, then I can accept or decline the nomination, hope that's OK :)

@thufschmitt
Copy link
Member

Yes, I can definitely shepherd that one 👍

@mweinelt
Copy link
Member

Sorry, not my cup of tea.

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/installer-test-suite-small-project-s-high-leverage-help-wanted/13662/5

@Ma27
Copy link
Member

Ma27 commented Nov 3, 2021

So, I'd be up for it if everyone else involved is OK with that :)

@tomberek
Copy link
Contributor

tomberek commented Nov 4, 2021

I can assist with this. I've been focusing on Nix itself for a bit. I'll self-nominate.

I've got an updated flake fork of the nix-install-matrix lying around that can track and test various scenarios - throw it up on a "Nix installer status page"?

@spacekookie spacekookie added status: in discussion and removed status: open for nominations Open for shepherding team nominations labels Nov 17, 2021
@spacekookie
Copy link
Member

Please update the RFC with the following shepherds: @Ericson2314, @regnat, @Ma27, @tomberek (leader). Thank you!

@tomberek
Copy link
Contributor

tomberek commented Nov 19, 2021

Plan of Action

created a room at #nix-rfc-106:matrix.org for any discussion

My guess is that the schedule and intent is not controversial. Focus on establishing some policy and guidance the community can depend on.

  1. Determine possible risks
  2. Establish a few possible and acceptable controls.
  3. Update RFC, with any policy-only controls
  4. FCP
  5. Merge
  6. Implement technical controls in parallel with 3-5
  7. Release another Nix version (apx: 2021 Dec 13)

@Ericson2314
Copy link
Member

So based on struggles I am having updating a client from 2.3 to 2.4, one thing I would like to see more of is testing of mixed clients/daemons/sshes as part of release-readiness. We've made NixOS/nix#5572 to test the new client with the old daemon, but I would also like to test the old client with the new daemon, and it is a but unclear what the best way to do that is.

@ck3d
Copy link

ck3d commented Nov 24, 2021

Regarding updating, I updated the daemon to 2.4pre and my services ran 2.3. After a few day I was confronted with NixOS/nix#5299 . I spend hours to fix the broken entries in the nix store.

@edolstra
Copy link
Member Author

On 1: That's out of scope for this RFC IMHO. We should probably have another RFC to decide on an experimental features policy.

On 2: Releasable state means that https://hydra.nixos.org/jobset/nix/master must be green. This is a superset of nix flake check.

On 3: That's me currently since I have the GPG signing key.

On 4: We should update the PR template to ask for release notes / documentation updates, if appropriate.

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-2-4-and-what-s-next/16257/1

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think having a arbitrary (reasonable) number of experimental features is too much of an issue. People shouldn’t be expected to just blindly buy into them, and having each feature guarded by an experimental flag gives more flexibility to rework/abandon them.

(Anyways, I think the usage of experimental features should be refined/standardized, but that’s out of scope for this RFC)

rfcs/0106-nix-release-schedule.md Outdated Show resolved Hide resolved
[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)?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dunno for the long-term releases, but I think we’ll have to do maintenance releases anyways, if only because we might have to do some bug fixes on the latest release before the end of the 6w cycle

Co-authored-by: Théophane Hufschmitt <regnat@users.noreply.github.com>
@tomberek
Copy link
Contributor

tomberek commented Dec 9, 2021

Update Plan of Action

  1. Determine possible risks complete
  2. Establish a few possible and acceptable controls. adding clarification
  3. Update RFC, with any policy-only controls
    a) update RFC to define "releasable state"
    b) updating issue template to nudge toward a more comprehensive test suite
  4. FCP
  5. Merge
  6. Implement technical controls in parallel with 3-5: out-of-scope and considered to be future work
  7. Release another Nix version (apx: 2021 Dec 13)

@NixOS/rfc-steering-committee: recommend moving this to FCP after RFC edits mentioned above. Shepherd team has general consensus and is recommending adoption.

@edolstra
Copy link
Member Author

@tomberek I've updated the RFC to define "releasable state" and mention the issue template.

@Mic92
Copy link
Member

Mic92 commented Dec 15, 2021

@tomberek do you think this RFC is now ready for FCP since the last commit?

@tomberek
Copy link
Contributor

@tomberek do you think this RFC is now ready for FCP since the last commit?

Yes.

@terlar
Copy link

terlar commented Dec 15, 2021

When it comes to back-porting fixes, how many versions back would receive backports with this new more frequent releases? Will the recommended way be to move forward to next version instead?

Also should the nix versions automatically be updated in nixpkgs as well? I notice now we do have a release of Nix 2.5.0. But nixpkgs for example have yet to be updated with this new release.

@edolstra edolstra added status: FCP in Final Comment Period and removed status: in discussion labels Jan 12, 2022
@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfc-106-fcp-nix-release-schedule/17096/1

@edolstra
Copy link
Member Author

Sorry, we forgot to announce the RFC on Discourse. I've done that now.

@terlar
Copy link

terlar commented Jan 12, 2022

What about my previous questions, are those things that should be part of the RFC?

E.g.

  • What is the back-porting policy?
  • Should the release process be connected in any way to nixpkgs?

@edolstra
Copy link
Member Author

We currently don't have a formal back-porting policy, so this RFC doesn't really change anything in that respect.

On the Nixpkgs release process, we probably want to maintain (i.e. back-port to) the default version used in the latest NixOS release.

@spacekookie spacekookie merged commit b5181c9 into NixOS:master Jan 26, 2022
@edolstra edolstra deleted the nix-release-schedule branch January 26, 2022 14:22
@edolstra
Copy link
Member Author

The RFC has been merged. Thanks everybody!

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-2022-what-was-great/24410/5

@infinisil infinisil added status: accepted and removed status: FCP in Final Comment Period labels Aug 23, 2023
KAction pushed a commit to KAction/rfcs that referenced this pull request Apr 13, 2024
* Nix release schedule
* Fix link
* Update rfcs/0106-nix-release-schedule.md

Co-authored-by: Théophane Hufschmitt <regnat@users.noreply.github.com>

* Add shepherds
* Update to reflect latest meeting

Co-authored-by: Théophane Hufschmitt <regnat@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.