-
Notifications
You must be signed in to change notification settings - Fork 59
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
Fetch updates from i.d.s by default #772
Conversation
Our goal is to deliver a solid experience with Nix flakes, including an upgrade path that is safe. Occasionally, the upstream Nix project may introduce regressions for the common flake path. This is not desirable for our users, who depend on a consistent and stable flakes experience. Additionally, the Nix project isn't directly responsible for delivering updates to users as that role is delegated to the Nixpkgs project. Overall, this means upgrades are not consistently delivered to users. This update directs future update requests to install.determinate.systems, which we will upgrade as part of our standard release process. Our standard release process includes proactive testing: validating our installer and Nix's behavior across a wide variety of platforms and scenarios. After an update passes our proactive validation, we do a phased rollout of reactive monitoring: the update is released to a small percentage of users on GitHub Actions. We monitor the failure rate of the installer and overall workflows to ensure the updated Nix isn't causing widespread failure we weren't able to identify ahead of time. Only after a release passes both proactive and reactive validation, our macOS .pkg and nix-upgrade paths are bumped to the most recent release. This gives user the confidence they're looking for that the Nix release they're getting is safe.
Closes #744 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me (though I note we did make the U
into u
)
The matching U -> u change is rolling out to install.determinate.systems shortly 👍 |
A couple days ago I upgraded my nix install and now I see a warning when running flakes
Removing the setting from |
The only side effect is that you won't get the latest Nix version when you run If you say you "upgraded" your Nix install but are now seeing that, it seems more likely that you downgraded it (whether on purpose or on accident)? That option was added in Nix 2.19.0 (NixOS/nix#9333), and this PR first appeared in What version of Nix are you using? |
Our goal is to deliver a solid experience with Nix flakes, including an upgrade path that is safe. Occasionally, the upstream Nix project may introduce regressions for the common flake path. This is not desirable for our users, who depend on a consistent and stable flakes experience.
Additionally, the Nix project isn't directly responsible for delivering updates to users as that role is delegated to the Nixpkgs project.
Overall, this means upgrades are not consistently delivered to users.
This update directs future update requests to install.determinate.systems, which we will upgrade as part of our standard release process.
Our standard release process includes proactive testing: validating our installer and Nix's behavior across a wide variety of platforms and scenarios.
After an update passes our proactive validation, we do a phased rollout of reactive monitoring: the update is released to a small percentage of users on GitHub Actions. We monitor the failure rate of the installer and overall workflows to ensure the updated Nix isn't causing widespread failure we weren't able to identify ahead of time.
Only after a release passes both proactive and reactive validation, our macOS .pkg and nix-upgrade paths are bumped to the most recent release. This gives user the confidence they're looking for that the Nix release they're getting is safe.
Description
Checklist
cargo fmt
nix build
nix flake check
Validating with
install.determinate.systems
If a maintainer has added the
upload to s3
label to this PR, it will become available for installation viainstall.determinate.systems
: