crystal: init at 0.29.0 #63725
crystal: init at 0.29.0 #63725
Conversation
|
This seems to break the scry package |
|
I would try updating the scry package to |
It doesn't - sorry, I had a few different commits here as I am using it on both stable and unstable and not all of it made it over... I have a fix for scry. Coming shortly. |
| # - 0.26.1 can build 0.25.x and 0.26.x but not 0.27.x | ||
| # - 0.27.2 can build 0.27.x but not 0.25.x and 0.26.x | ||
| # - 0.27.2 can build 0.27.x but not 0.25.x, 0.26.x and 0.29.x |
There was a problem hiding this comment.
I'm intrigued by how crystal is starting to become maintained in nixpkgs.
Is there are stable change to be done once a new version is released?
Usually the last 0.m.p version should be used to build any 0.(m+1).q version. That is how Crystal releases works. That is the rule that should be followed since the compiler is bootstrapped. Although in the past there were some hiccups with this rule.
In brew, when 0.m.p is released we built that tag using the GitHub binary release of the latest 0.m-1.q version.
But from what I "understand" from the formula after a first version of the compiler got into nix the new ones are built after it. Having a new lineage. Am I right?
|
Answering out of order, as that makes things a little easier to follow (for me at least).
But from what I "understand" from the formula after a first version of the
compiler got into nix the new ones are built after it. Having a new
lineage. Am I right?
No - the previous versions of "our" compiler are not used for building crystal - we use the binary distribution. If the latest binary we have is not able to, we will simply bump the binary to the latest and then use that.
That is how Crystal releases works. That is the rule that should
be followed since the compiler is bootstrapped.
Is it an issue that we don't do it that way?
Is there are stable change to be done once a new version is released?
It's always a balancing act between the number of packages we are interested in carrying and what the needs of the users are.
Basically, how I do it is this way:
- when stable is branched off from unstable (near a release of NixOS), this is the version that will stay for the lifetime of stable (6 months until the next stable).
- in unstable we have at minimum the latest version plus whatever version was in the last stable.
We don't backport new crystal versions to stable. Although it's trivial to do, backports are reserved for security fixes.
|
|
Thanks for the clarifications and porting crystal to nixpkgs.
It's not necessarily an issue. From the comments, it sounded to me like there was some research on which compiler should be used. It seems like a trial an error procedure is made to check if a bump is needed. As long as the compiler specs passes and the std passes with the new compiler then the behavior should be good enough. Ideally, the progress of the compiler should be guaranteed (ie: the new compiler can build itself again). |
That's exactly how it was done, so your explanation clears that up. I'll update the comment in there.
Yeah, that's the problem. It doesn't. We're pretty close but not quite there. It basically has to do path assumptions in the specs that fail when we build using nix. Ideally, the progress of the compiler should be guaranteed (ie: the new compiler can build itself again). |
Motivation for this change
Supersedes #63427
Fixes #63039
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nix-review --run "nix-review wip"./result/bin/)nix path-info -Sbefore and after)