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

nixos/doc/releases: Do not tag the release #124364

Closed
wants to merge 1 commit into from

Conversation

roberth
Copy link
Member

@roberth roberth commented May 25, 2021

I have seen a customer use the release tag as a pinned version
and the same can happen in flake input urls or similar input
configs, like niv --branch.
This results in a out of date version of the all system
packages, putting users at risk of security vulnerabilities
and other issues that are addressed during the lifetime of a
Nixpkgs/NixOS release.

So clearly the tag poses a risk, but does it have a benefit?
I don't think so. It does not name the branch-off point, so we
don't need it for git operations. It does not represent the
best or canonical version of the release either, as further
fixes always occur after the release date. If it were the case,
we'd tag all channel updates, but we don't, so for the same
reasons, we should not tag the release.

Motivation for this change

Always use the latest version.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Added a release notes entry if the change is major or breaking
  • Fits CONTRIBUTING.md.

I have seen a customer use the release tag as a pinned version
and the same can happen in flake input urls or similar input
configs, like `niv --branch`.
This results in a out of date version of the _all_ system
packages, putting users at risk of security vulnerabilities
and other issues that are addressed during the lifetime of a
Nixpkgs/NixOS release.

So clearly the tag poses a risk, but does it have a benefit?
I don't think so. It does not name the branch-off point, so we
don't need it for git operations. It does not represent the
best or canonical version of the release either, as further
fixes always occur after the release date. If it were the case,
we'd tag all channel updates, but we don't, so for the same
reasons, we should not tag the release.
@r-rmcgibbo

This comment has been minimized.

@roberth

This comment has been minimized.

@nixos-discourse
Copy link

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

https://discourse.nixos.org/t/removing-the-nixos-release-tag/13255/1

@NobbZ
Copy link
Contributor

NobbZ commented May 25, 2021

Please stick to tagging the release branch-off commit! It's useful when git describeing something.

@roberth
Copy link
Member Author

roberth commented May 25, 2021

Thank you @NobbZ.
That does seem useful indeed. Perhaps we can find another way to prevent this mistake.
Prefixing v as in v21.05 may be helpful, or warnings in the tooling.

@roberth roberth closed this May 25, 2021
@gebner gebner reopened this May 25, 2021
@gebner
Copy link
Member

gebner commented May 25, 2021

I also find it confusing that the tags point to an essentially random revision (and might have made the same mistake as your customer). I don't think we use this tag anywhere either; even the ISO downloads are made from the release-* branch.

@edolstra
Copy link
Member

Maybe we could use a different name for the branch-off tag, like 21.05-initial, to convey that it's just the start of the 21.05 branch.

@jonringer
Copy link
Contributor

This is the wrong location for doing release documentation updates. the release guide has moved to https://github.com/NixOS/release-wiki

@jonringer
Copy link
Contributor

hmm, guess I should remove the reference to this section in the current docbook build

@ryantm ryantm reopened this May 25, 2021
@ryantm
Copy link
Member

ryantm commented May 25, 2021

I guess discussion on this can continue in the https://github.com/NixOS/release-wiki repo.

@roberth
Copy link
Member Author

roberth commented May 26, 2021

I guess discussion on this can continue in the https://github.com/NixOS/release-wiki repo.

NixOS/release-wiki#13

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.

8 participants