-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
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
swiProlog: 9.1.21 -> 9.2.5 #325280
swiProlog: 9.1.21 -> 9.2.5 #325280
Conversation
LGTM, but please tag the person who originally made the switch to |
@barakber according to git history you originally upgraded swi-prolog from 7.6.4 to 8.1.4 back in 2019 (990acf7), along with various improvements to the packaging. This switched the version of swi-prolog in nixpkgs from stable to devel. In this PR I am going back to tracking stable. I think it makes more sense to track stable, as this allows more easy backporting of fixes. Since we're going from 9.1.21 to 9.2.5, this should be a mostly clean upgrade path for people (as clean as it can be from a development version anyway). |
Why not both? A |
I'm fine with both. But I feel strongly that the default should be stable. Also, I don't think this PR has to be held up until that is implemented. Nobody really loses anything in this move to stable. People who might have relied on features under development in 9.1 will find these features stabilized in 9.2. Luckily 9.1.21 is pretty late in the dev cycle so it should be pretty close already. |
You are correct. |
Description of changes
This upgrades SWI-Prolog to the latest stable. See the changelog for more details.
Note that it appears to have been established practice in this package to import a development version of the SWI-Prolog source, though I haven't been able to find an indication that this was intentional. I am intentionally upgrading to a stable version instead, with the hope that from now on, this package will track SWI-Prolog stable.
SWI-Prolog stable versions only receive backported fixes after release, whereas in the development versions, anything goes, including backwards-incompatible breaks with previous versions of the same minor number. This means stable is suitable for doing backports to released versions of nixpkgs, while the development version is not.
I left some comments in the package source to point this out, in the hope that future importers will not accidentally pull in a dev version.
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)