Most eggs in the canonical repository don't declare a `version` property in their `.egg` files. This
is because it's provided implicitly when using `chicken-install` to retrieve them. Quoting from [the
manual](https://wiki.call-cc.org/man/5/Egg%20specification%20format#version):
> Eggs from remote egg servers are automatically versioned - the version is part of the protocol to
retrieve the egg and does not have to be specified in the .egg file.
Since we don't use `chicken-install` to retrieve eggs, this leaves us with a version of "unknown" in
most cases, e.g.:
$ nix-shell -p chickenPackages.chickenEggs.json-abnf chickenPackages.chicken --run chicken-status
abnf ...................................................... version: unknown
iset ...................................................... version: unknown
json-abnf ................................................. version: unknown
lexgen .................................................... version: unknown
regex ......................................................... version: 2.0
srfi-1 .................................................... version: unknown
srfi-127 .................................................. version: unknown
srfi-69 ................................................... version: unknown
utf8 ...................................................... version: unknown
This is usually not an issue unless another egg declares a minimum required version dependency on an
egg with missing version info. In this case, `chicken-install` will fill in "0.0.0" as a fallback
and the check will fail. This has so far been worked around patches (see e.g. #346004 or #358455).
This patch addresses the root cause by following the documentation's recommendation:
> Eggs installed from local directories (see below) should explicitly specify a version.
To do that, `eggDerivation` now simply always adds the version to the generated `.egg-info`
file. This has the added benefit of correcting potentially inconsistent version declarations in
`.egg` files. Note that we cannot patch the original `.egg` file because not all released egg
versions match [the stricter version format validation which currently applies
there](https://bugs.call-cc.org/ticket/1855).
The patch also changes the signature of `eggDerivation` to allow passing in `pname` and `version`
instead of `name` to allow for easy access to the egg version. However, for backwards compatibility,
the old `name` argument is also still supported.
As a result, the aforementioned overrides are removed again and some additional eggs can be marked
as unbroken again.
And finally, this is the output of the above `chicken-status` call with the patch applied:
$ nix-shell -p chickenPackages.chickenEggs.json-abnf chickenPackages.chicken --run chicken-status
abnf .......................................................... version: 8.3
iset .......................................................... version: 2.2
json-abnf ..................................................... version: 7.0
lexgen ........................................................ version: 8.2
regex ......................................................... version: 2.0
srfi-1 ...................................................... version: 0.5.1
srfi-127 ...................................................... version: 1.3
srfi-69 ..................................................... version: 0.4.3
utf8 ........................................................ version: 3.6.3
Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
- Released output styles, including new built-in educational output styles "Explanatory" and "Learning"
- Plugin system improvements for repository installation messaging and error handling
- Agents: Fixed an issue with custom agent loading when agent files are unparsable
We also need to symlink libexec when doing fastCross.
It contains rust-analyzer-proc-macro-srv which rust-analyzer needs for proc macro expansion to work.
Splits the "occasionally" case into two, depending on whether the commit
has a diff or was not cherry-picked at all. Prepares the next commit,
where these are conditionally shown only.
This change allows giving a reason via footer of the commit message for
why this commit is not cherry-picked. This avoids having to "explain"
the automated review comment afterwards - instead, this explanation can
be given immediately when writing that commit.
For example, for an update of `xen` on the stable branch, this could be:
```
xen: 4.19.3-unstable-2025-07-09 -> 4.19.3
[... commit message ...]
Not-cherry-picked-because: unstable is on a different minor version
```
This would then be shown as part of the automated review. The severity
of this will be downgraded from "warning" to "important". We still treat
the review as "changes requested", because it would be very complicated
and noisy to handle two different categories of reviews, some with
requested changes and some with comments only.
An alternative would be to not show this review at all. However, given
that the reviewers expectation on backports should already be "if it's
not a clean backport, the automated review will tell me what to look
at", it seems better to show these and have the committer confirm by
dismissing the review. Otherwise we risk merging actually unreviewed
commits.
