there's also some related TODO(MSRV)

Yeah, I'm focusing on those next.

FWIW going forward I'd probably not bother with announcing the exact number every time, it's probably enough to make it obvious how to find the MSRV that corresponds to a tarball or git commit.

Hm, I guess distributors will notice when they try to build with a toolchain that's too old. I thought it might be nice to give a heads-up, but maybe it's not necessary.

it would definitely be nice to packagers (and maybe other users?) to mention it but I don't think it's tragic if we forget or are too lazy.
(Looking for msrv in .github/ seems more reliable in CHANGELOG.rst but I guess it's subjective).

For "automatic changelog generation" there is https://git-cliff.org/
not sure if it works for our use case

Yes, it just nice to have, but not a big deal if we forget it. For something that changes as infrequently as the MSRV with our current policy, I don't think it's worth bothering with automation. Automation might be nice for other things, but I suspect that it would be more effort to enforce a specific commit message style than to write the changelog manually, especially if we don't want every commit to contribute to the changelog.

I think it's worth including.

The cirrus tasks for Alpine and Ubuntu (jammy) seem to use images under your control.

yeah I did that because I didn't have access.
There's ongoing work to switch them back, see #11884 and below

For Ubuntu, we might want to switch to a more recent release.

Yeah actually looking at either of

• https://github.com/fish-shell/fish-shell/pull/11679/files
• https://packages.ubuntu.com/search?keywords=rustc&searchon=all&suite=all&section=all

it seems that Ubuntu is lagging a bit behind in rustc versions.

If it helps users, we could certainly lower the Rust version to say, 1.80 or 1.84.
But of course the main goal for now is to get any progressive MSRV going, we can always tweak it later.
No strong opinion.

Since Ubuntu Jammy (LTS) is supported until 2027,
we might want to keep running tests:

set -eu
today=$(date --iso-8601)
# fetch (or pipe JSON into this script). Example uses endoflife.date API.
curl -fsSL https://endoflife.date/api/ubuntu.json |
  jq -r --arg today "$today" '
    (if type=="object" then [.] else . end)
    | .[]
    | {
        codename: (.codename? // .name // .cycle // "-"),
        version: (.cycle? // .version? // .latest // "-"),
        eol_raw: (.eol? // .eol_date? // .support? // .end_of_life? // .support_end? // null)
      }
    | . as $it
    | ($it.eol_raw // "") as $e
    | ($e | tostring | sub("Z$";"")) as $e_str
    | select($e_str != "" and $e_str >= $today)
    | "\($it.codename)\t\($it.version)\t(\($e_str))"
  ' | sort -r | column -t -s '	'
Questing Quokka  25.10  (2026-07-01)
Plucky Puffin    25.04  (2026-01-17)
Noble Numbat     24.04  (2029-04-25)
Jammy Jellyfish  22.04  (2027-04-01)

so for Cirrus we can either

1. keep Jammy but install rust from curl rustup.sh (which is probably what our GitHub Actions CI does)
2. upgrade from Jammy to Noble which ships rustup, then use rustup
3. abandon Ubuntu completely (except for GitHub Actions, where we already use dtolnay/rust-toolchain@$MSRV) and use the more up-to-date debian stable

If I find time to work on this, I'll add a script to #11960
to check if our .cirrus.yml versions are still up-to-date.
That would be desirable if we do option 1;
it would be trivial if we use option 3,
and it might not be clear what's the Ubuntu version policy if we do option 2, which speaks against option 2.

I think option 1 sounds like the most foolproof and fastest to get going for now.

In any case, I can't fix those myself.

Documentation is lacking; there's three possibilities:

1. the old approach: build the images in docker/ and use docker push to your own registry and update .cirrus.yml to point to those

2. Run .github/workflows/build_docker_images.yml on your fork (either by pushing to master or with gh --repo $gh_user/fish-shell workflow run --ref=...).
   This will also create the container images in your namespace

3. hopefully the standard approach in future:
   It should be handled completely transparently by .github/workflows/build_docker_images.yml.
   Today that already happens on pushes to master, but can also do
   gh workflow run --ref=... (you should have access now as org member)

   There are two potential problems with this:

   1. it runs only on master so PRs are not tested until they are merged (Bravely revert "CI: Disable some Cirrus CI jobs during RIIR transition" #11884 (comment))
   2. even when pushing directly to master, there is a CI orchestration problem: test.yml runs concurrently with build_docker_images.yml even though it depends on it. See Bravely revert "CI: Disable some Cirrus CI jobs during RIIR transition" #11884 (comment)

   I'm not yet sure if these are blockers, which is why we haven't switched to fish-shell/fish-ci yet

Sorry for all the historical baggage.
But I'd definitely trade a little velocity for the opportunity to crack down hard on all the short-sighted engineering practices of the past,
especially as the PR review queue keeps growing.

I should be able to update Cirrus images for alpine/ubuntu today (manual update though)

I'll wait to merge until tomorrow morning (in case we want to avoid problems with OBS builds),
but going forward, green github CI will be enough.

I'd definitely trade a little velocity for the opportunity to crack down hard on all the short-sighted engineering practices of the past,
especially as the PR review queue keeps growing.

Yeah, cleaning up some of that to simplify development in the future is certainly desirable. It's not like we are in a big rush to get this merged.

I think the only real reason not to use rustup everywhere is that making network requests during package builds is frowned upon. As I understand it that's also the primary reason why we can't just set our MSRV to stable. But our CI checks don't have to worry about that, they can use rustup as we please. So we only need to ensure that our MSRV is supported on the distros which package Rust, possibly only the ones where we offer our own builds. I think @zanchey has managed that, so I think we should confirm that this PR does not cause problems with our own builds (https://build.opensuse.org/package/show/shells:fish/fish, https://launchpad.net/~fish-shell/+archive/ubuntu/release-4)

for Cirrus we can either

I think options 1 and 2 are compatible. If we ensure that rustup is installed in the images, we could even keep the matrix approach. There is also the linux_arm_task which seems to have been disabled for fish's Rust rewrite. Maybe we can reactivate that now and simplify to a single matrix task for Linux.

abandon Ubuntu completely

I don't know what the motivation for adding Ubuntu to Cirrus was in the first place. It doesn't seem to do anything not already done in gh CI, other than testing on different distro versions, which can be valuable. If we explicitly base our version policies around Debian, it certainly wouldn't hurt to actually test on Debian. I don't have much of an opinion on whether we should keep testing on Ubuntu. If we can do so without much effort on our part or exhausting build resources, I guess it's nice to keep it around, but I also wouldn't mind abandoning it.

If it helps users, we could certainly lower the Rust version to say, 1.80 or 1.84.

That's an option. I guess it again comes down to which distros and versions we want to support without requiring rustup. "whatever's in Debian stable" is fairly simple, but maybe a more complex policy is more appropriate for us. The main benefit of Rust 1.85 is that it introduces the 2024 edition. Other than that, I think Rust 1.83 is the oldest version which probably still works with all the changes in #11964 (we don't have to merge all of those now, of course). To make a reasonably well-informed decision, we might want to wait to see if zanchey has any comments.

Probably Debian/1.85 is fine, but if it helps anyone, we might also
do something like 1.83 (Debian-2).

In any case, now that we no longer support really old macOS,
we should probably use stable here, like for other builds:

diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index f97e35cdfd..c1d139c047 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -143,13 +143,9 @@
           # Workaround for https://github.com/actions/checkout/issues/882
           ref: ${{ inputs.version }}
       - name: Install Rust
-        uses: ./.github/actions/rust-toolchain@oldest-supported
-        with:
-          targets: x86_64-apple-darwin
-      - name: Install Rust Stable
         uses: ./.github/actions/rust-toolchain@stable
         with:
-          targets: aarch64-apple-darwin
+          targets: aarch64-apple-darwin,x86_64-apple-darwin
       - name: Install dependencies
         run: brew install gettext
       - name: Build and codesign
diff --git a/build_tools/make_macos_pkg.sh b/build_tools/make_macos_pkg.sh
index 78bfe044a8..970a2ae3db 100755
--- a/build_tools/make_macos_pkg.sh
+++ b/build_tools/make_macos_pkg.sh
@@ -26,12 +26,6 @@
 ARM64_DEPLOY_TARGET='MACOSX_DEPLOYMENT_TARGET=11.0'
 X86_64_DEPLOY_TARGET='MACOSX_DEPLOYMENT_TARGET=10.9'
 
-# As of this writing, the most recent Rust release supports macOS back to 10.12.
-# The first supported version of macOS on arm64 is 10.15, so any Rust is fine for arm64.
-# We wish to support back to 10.9 on x86-64; the last version of Rust to support that is
-# version 1.73.0.
-RUST_VERSION_X86_64=1.85.0
-
 while getopts "sf:i:p:e:nj:" opt; do
     case $opt in
         s) SIGN=1;;
@@ -65,34 +59,29 @@
 
 mkdir -p "$PKGDIR/build_x86_64" "$PKGDIR/build_arm64" "$PKGDIR/root" "$PKGDIR/intermediates" "$PKGDIR/dst"
 
+do_cmake() {
+    cmake \
+        -DCMAKE_BUILD_TYPE=RelWithDebInfo \
+        -DCMAKE_EXE_LINKER_FLAGS="-Wl,-ld_classic" \
+        -DCMAKE_OSX_ARCHITECTURES='arm64;x86_64' \
+        -DFISH_USE_SYSTEM_PCRE2=OFF \
+        "$@" \
+        "$SRC_DIR"
+}
+
 # Build and install for arm64.
 # Pass FISH_USE_SYSTEM_PCRE2=OFF because a system PCRE2 on macOS will not be signed by fish,
 # and will probably not be built universal, so the package will fail to validate/run on other systems.
 # Note CMAKE_OSX_ARCHITECTURES is still relevant for the Mac app.
 { cd "$PKGDIR/build_arm64" \
-    && cmake \
-        -DCMAKE_BUILD_TYPE=RelWithDebInfo \
-        -DCMAKE_EXE_LINKER_FLAGS="-Wl,-ld_classic" \
-        -DRust_CARGO_TARGET=aarch64-apple-darwin \
-        -DCMAKE_OSX_ARCHITECTURES='arm64;x86_64' \
-        -DFISH_USE_SYSTEM_PCRE2=OFF \
-        "$SRC_DIR" \
+    && do_cmake -DRust_CARGO_TARGET=aarch64-apple-darwin
     && env $ARM64_DEPLOY_TARGET make VERBOSE=1 -j 12 \
     && env DESTDIR="$PKGDIR/root/" $ARM64_DEPLOY_TARGET make install;
 }
 
 # Build for x86-64 but do not install; instead we will make some fat binaries inside the root.
-# Set RUST_VERSION_X86_64 to the last version of Rust that supports macOS 10.9.
 { cd "$PKGDIR/build_x86_64" \
-    && cmake \
-        -DCMAKE_BUILD_TYPE=RelWithDebInfo \
-        -DCMAKE_EXE_LINKER_FLAGS="-Wl,-ld_classic" \
-        -DRust_TOOLCHAIN="$RUST_VERSION_X86_64" \
-        -DRust_CARGO_TARGET=x86_64-apple-darwin \
-        -DRust_COMPILER="$(rustup +$RUST_VERSION_X86_64 which rustc)" \
-        -DRust_CARGO="$(rustup +$RUST_VERSION_X86_64 which cargo)" \
-        -DCMAKE_OSX_ARCHITECTURES='arm64;x86_64' \
-        -DFISH_USE_SYSTEM_PCRE2=OFF "$SRC_DIR" \
+    && do_cmake -DRust_CARGO_TARGET=x86_64-apple-darwin \
     && env $X86_64_DEPLOY_TARGET make VERBOSE=1 -j 12; }
 
 # Fatten them up.

X86_64_DEPLOY_TARGET='MACOSX_DEPLOYMENT_TARGET=10.9'

Should this be changed to 10.12? Or also 11.0? The old comment claims that arm64 is supported since 10.15, so I'm not sure why 11.0 is used there. But I'm also generally unfamiliar with packaging for macOS.

right, it should be 10.12. I also don't know why this arm64 deployment target is used

I added the diff and the change to 10.12 to the PR.