Ideally we want to credit reported-by/helped-by etc. but we'd need
to ask the GitHub API for this information.
Also we should use %(trailers) if possible.
When users update fish by replacing files, existing shells might
throw weird errors because internal functions in share/functions/
might have changed.
This is easy to remedy by restarting the shell,
but I guess it would be nice if old shells kept using old data.
This is somewhat at odds with lazy-loading.
But we can use the standalone mode. Turn that on by default.
Additionally, this could simplify packaging. Some packages incorrectly
put third party files into /usr/share/fish/completion/ when they ought
to use /usr/share/fish/vendor_completions.d/ for that. That packaging
mistake can make file conflicts randomly appearing when either fish
or foo ships a completion for foo. Once we actually stop installing
/usr/share/fish/completions, there will no longer be a conflict (for
better or worse, things will silently not work, unless packagers
notice that the directory doesn't actually exist anymore).
The only advantage of having /usr/share/fish/ on the file system is
discoverability. But getting the full source code is better anyway.
Note that we still install (redundant) $__fish_data_dir when using
CMake. This is to not unnecessarily break both
1. already running (old) shells as users upgrade to 4.2
2. plugins (as mentioned in an earlier commit),
We can stop installing $__fish_data_dir once we expect 99% of users
to upgrade from at least 4.2.
If we end up reverting this, we should try to get rid of the embed-data
knob in another way, but I'm not sure how.
Closes#11921
To-do:
- maybe make it a feature flag so users can turn it off without
recompiling with "set -Ua no-embed-data".
The new automation workflow doesn't sign the Git tag or the tarball as
we used to. Since the tag is still created locally, sign it directly.
For signing the tarball; build it locally and compare the extracted
tarball with the one produced by GitHub.
Closes#11996
GitHub CI uses shallow clones where no Git tags available, which
breaks tests/checks/sphinx-markdown-changelog.fish.
Somehow tests/checks/sphinx-markdown-changelog.fish doesn't seem to
have run CI before the next commit (or perhaps the python3 change
from commit "tests/sphinx-markdown-changelog: workaround for mawk",
2025-10-26?).
Anway, to prevent failure, disable that part of this test in CI
for now; the point of the test is mostly to check the RST->Markdown
conversion and syntax.
Our test driver unsets all LC_* variables as well as LANGUAGE, and
it sets LANG=C, to make errors show up as
set_color: Unknown color 'reset'
rather than
set_color: Unknown color “reset”
It also sets LC_CTYPE which is hardly necessary since c8001b5023
(encoding: use UTF-8 everywhere, 2025-10-18).
The only place where we need it seems to be the use of GNU sed as
called in tests/checks/sphinx-markdown-changelog.fish.
In future we might want to avoid these issues by setting LANG=C.UTF-8
in the test_driver again.
Integration_4.1.1 fails to generate release notes with
CHANGELOG.rst:9: WARNING: Bullet list ends without a blank
line; unexpected unindent. [docutils].
Instead of adding these to the Markdown directly, add it to the
fake CHANGELOG.rst source, which makes escaping easier, and allows
generating other formats than Markdown in future.
GitHub-flavored Markdown translates line breaks to <br/>, which does
not match our intent. Work around that by joining lines when producing
Markdown output.
System tests typically run outside the workspace directory, but they
still have read-only access to the workspace; fix it accordingly.
This test only works on git checkouts, not in tarballs, so skip it
if .git doesn't exist.
Instead of having sphinx-build only build CHANGELOG.rst, build the
entire thing, so relative references (":doc:", ":ref:") can be resolved
properly. Replace our sed-based hacks with 'markdown_http_base'.
