-
-
Notifications
You must be signed in to change notification settings - Fork 15.1k
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
coq_8_13: init at 8.13+β1 #106427
coq_8_13: init at 8.13+β1 #106427
Conversation
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.
LGTM, thanks for clarifying the minimality of changes to math-comp packages.
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.
Can we limit the amount of packages? I don't think we need 10 versions in nixpkgs.
I agree that ten versions of Coq might be too much. In particular compatibility across versions is much better than what it used to be. How many of them should we keep? And which ones? |
Result of 1 package built:
|
How does this selection work in other languages? I think for OCaml we also keep all the versions in a given range (currently, we have 13, from OCaml 4.00 to OCaml 4.12). Are there examples of language compilers for which some intermediate versions are dropped from nixpkgs? |
A data point: there is this issue, that is still open #54556 |
General rule is 3 versions. I think terrarform is a recent example I have seen. Keeping all patch versions is not required. We can keep different major versions and minor versions of there is a use case. |
Terraform is probably not the best comparison because it's not a language compiler. In nixpkgs, language compilers tend to have many more versions than 3. I gave the OCaml example (with its 13 versions) because this is the example I know the most, but I'd be interested in other examples. Python for instance has 2.7, 3.6, 3.7, 3.8, 3.9. It seems like a reasonable strategy to drop very old versions (especially when they become a hassle to maintain) but to keep a whole range between the oldest supported and the latest version. Patch-level releases are indeed probably not useful, but not a problem either if they only add one line with a Another aspect to take into consideration is the release frequency and the level of compatibility between releases. In the case of Coq, major releases are frequent (every 6 months) and introduce incompatibilities (although not as many as before) that tend to require an update of the packages that depend on Coq. |
Let’s merge this so that we can update 8.12 to 8.12.2 and avoid merge conflicts. |
Motivation for this change
Prepare for the next release: https://github.com/coq/coq/releases/tag/V8.13%2Bbeta1
NB: the addition of mathcomp libraries at version 1.12 is just to fix the build with Coq 8.13: it’s a minimal change to avoid conflicts and work duplication with Cyril’s refactoring (in #105877).
cc maintainers @roconnor @thoughtpolice @Zimmi48
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)