build: drop Intel macOS, and stop recommending prereleases - #180
Merged
Merged
Conversation
macOS 26 Tahoe is the last release Apple ships for Intel at all -- 27 requires Apple Silicon, and Intel Macs get security updates only, for about three years. Nobody maintaining this has an Intel machine, so darwin/amd64 was a binary shipped on faith to a platform on its way out. This reverses c03b1ff, which added the build a few days ago. That change was right for the question it answered: the repo is its own Homebrew tap, so the build matrix is the install matrix, and without darwin/amd64 the generated cask carried no on_intel block and `brew install` failed outright on an Intel Mac. What it did not ask was whether Intel macOS should be supported at all. Answered now, and the answer makes the missing on_intel block correct rather than a gap -- verified by rendering: `goreleaser release --snapshot` now builds three targets and the cask's on_macos holds on_arm alone. The consequence is deliberate and worth remembering before someone "fixes" it: `brew install markfluence` fails on an Intel Mac with no artifact for the platform. The README says so and sends those users to a source build. There is no partial support here -- re-adding the platform means re-adding the build. Prereleases get the same treatment in the other direction. docs/releasing.md recommended `v1.2.3-rc.1` as the way to rehearse a release; this project has never cut a prerelease and does not intend to, so recommending one is advice nobody follows. The runbook now points at the local snapshot build as the rehearsal, which publishes nothing and is the better test anyway. release.prerelease: auto and the cask's skip_upload: "auto" both stay, marked as insurance rather than workflow. One line each against a failure that would be silent: without them an RC tag publishes as a normal release and becomes /releases/latest, or bumps the cask for `brew install` users. Both are recorded as never having run. Refs #1, #29.
This was referenced Sep 21, 2026
willkg
added a commit
that referenced
this pull request
Sep 21, 2026
Code review of the move found four ways the previous commit's warning failed to do its job. **The list was incomplete in exactly the way it existed to prevent.** It named three couplings; there are five. The action also fetches checksums.txt by the name `checksum.name_template` produces, and untars, so `archives.formats` matters too -- rename either and every consumer's job fails at install, with `make check` green and a release already out. The "three things" framing read as exhaustive, so it is now an explicit list with no count. **The warning was only in the file nobody has open when the mistake happens.** .goreleaser.yaml said nothing about the action at all. Dropping Intel macOS (#180) is the cited example of a coupled change and it landed here with no pointer anywhere a maintainer editing `builds.ignore` would see it. Each of the four blocks the action reads -- builds.ignore, archives, checksum, release -- now says so where it is edited. **The tag-glob rationale was left contradicting the new paragraph two lines below it.** CLAUDE.md, release.yml and docs/releasing.md all justified `v*.*.*` as keeping out "the moving major tag #29 needs" -- a tag that will now never exist here, since the action has its own repository. A guard standing on a reason a reader can disprove is a guard the next person relaxes. All three now give the reason that is still true: goreleaser refuses a non-semver tag, and `v1` and `v1.2` are not semver, so a bare `v*` would start a run that could only fail. The old reason is kept as history where it is worth knowing, with "do not relax it" said outright. **The present tense was ahead of reality.** CLAUDE.md said the action "lives in" the new repository while that repository holds only a LICENSE and its first pull request is open. It now says the action is *built* there and has not shipped, and docs/github-actions.md -- the only user-facing mention, which still routed readers to #29 with no hint the repository exists -- says the same thing from the reader's side, and that this page stays the canonical copy of the recipe until the action lands. Also, found while in that file: the workflow example still claimed no release binaries were published and installed `@latest`. v0.1.0 is out, so it pins a tag, and notes that `go install` produces no version stamp.
willkg
added a commit
that referenced
this pull request
Sep 22, 2026
mozilla/markfluence-action holds it now (#29). The design in _plans/047 transferred intact -- the findings, the phases and the constraints are all unchanged -- so this records where the code went and why, rather than rewriting the plan. The reason is release cadence. In this repository the action's releases are welded to the CLI's: a one-line fix to the installer could not reach anyone until a whole markfluence release was cut, which is backwards, since the action changes most in its first months and the CLI is the stable half. A separate repository also lets the action be v1 immediately instead of waiting for markfluence 1.0.0 to make `uses: ...@v1` meaningful. The alternative was a second tag prefix like action-v1.0.0 here, which is two tag namespaces in one repository -- worse than two repositories. Split at zero consumers, which is the cheapest it will ever be. The cost is recorded rather than glossed: coordinated changes are now two pull requests with nothing linking them, where dropping Intel macOS (#180) was one commit and one CI run. CLAUDE.md names the three things over here the action depends on -- the archive naming from goreleaser's name_template, the platform set, and release.draft plus prerelease: auto keeping /releases/latest trustworthy -- because nothing in `make check` will catch a mismatch.
willkg
added a commit
that referenced
this pull request
Sep 22, 2026
Code review of the move found four ways the previous commit's warning failed to do its job. **The list was incomplete in exactly the way it existed to prevent.** It named three couplings; there are five. The action also fetches checksums.txt by the name `checksum.name_template` produces, and untars, so `archives.formats` matters too -- rename either and every consumer's job fails at install, with `make check` green and a release already out. The "three things" framing read as exhaustive, so it is now an explicit list with no count. **The warning was only in the file nobody has open when the mistake happens.** .goreleaser.yaml said nothing about the action at all. Dropping Intel macOS (#180) is the cited example of a coupled change and it landed here with no pointer anywhere a maintainer editing `builds.ignore` would see it. Each of the four blocks the action reads -- builds.ignore, archives, checksum, release -- now says so where it is edited. **The tag-glob rationale was left contradicting the new paragraph two lines below it.** CLAUDE.md, release.yml and docs/releasing.md all justified `v*.*.*` as keeping out "the moving major tag #29 needs" -- a tag that will now never exist here, since the action has its own repository. A guard standing on a reason a reader can disprove is a guard the next person relaxes. All three now give the reason that is still true: goreleaser refuses a non-semver tag, and `v1` and `v1.2` are not semver, so a bare `v*` would start a run that could only fail. The old reason is kept as history where it is worth knowing, with "do not relax it" said outright. **The present tense was ahead of reality.** CLAUDE.md said the action "lives in" the new repository while that repository holds only a LICENSE and its first pull request is open. It now says the action is *built* there and has not shipped, and docs/github-actions.md -- the only user-facing mention, which still routed readers to #29 with no hint the repository exists -- says the same thing from the reader's side, and that this page stays the canonical copy of the recipe until the action lands. Also, found while in that file: the workflow example still claimed no release binaries were published and installed `@latest`. v0.1.0 is out, so it pins a tag, and notes that `go install` produces no version stamp.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two decisions that came out of reviewing what was left on #1 and #175 after
v0.1.0shipped. Both narrow what the project claims to support, in opposite directions.No Intel macOS build
macOS 26 Tahoe is the last release Apple ships for Intel — macOS 27 requires Apple Silicon, and Intel Macs get security updates only, for roughly three years. Nobody maintaining this has an Intel machine, so
darwin/amd64was a binary shipped on faith to a platform on its way out.This reverses c03b1ff, from a few days ago. That change was right for the question it answered: the repo is its own Homebrew tap, so the build matrix is the install matrix, and without
darwin/amd64the generated cask carried noon_intelblock andbrew installfailed outright on an Intel Mac. What it never asked was whether Intel macOS should be supported at all. Answered now — and the answer makes the missingon_intelblock correct rather than a gap.Verified by rendering rather than by reasoning:
goreleaser release --snapshotnow builds three targets, and the cask'son_macosholdson_armalone.The consequence is deliberate and is written into both the config and the README, because it looks like a bug to anyone who finds it later:
brew install markfluencefails on an Intel Mac with no artifact for the platform, and those users are sent to a source build. There is no partial support — re-adding the platform means re-adding the build.No prereleases, and the config says why it still handles them
docs/releasing.mdrecommendedv1.2.3-rc.1as the way to rehearse a release. This project has never cut a prerelease and does not intend to, so that was advice nobody follows. The runbook now points at step 2's local snapshot build, which publishes nothing and is a better test than a real tag anybody can see.release.prerelease: autoand the cask'sskip_upload: "auto"both stay, reframed as insurance rather than workflow. One line each against a failure that would otherwise be silent: without them an RC tag publishes as a normal release and becomes/releases/latest, or bumps the cask forbrew installusers. Both are now marked in the config as never having run, which is their honest status.Also updated
CLAUDE.md— three archives rather than four, and the rule that makes it matter: because the repo is its own tap, the build matrix is the install matrix, so a platform absent from it is one the cask cannot serve._plans/047_github-action.md— its runner table saidmacos-13✅. That plan is unimplemented, so a stale table would have misled whoever picks up #29;macos-13andwindows-latestare now both "not built", and the installer's named-error requirement covers both again.Worth knowing, not fixed here
Casks/markfluence.rbonmainstill carries anon_intelblock pointing atmarkfluence_0.1.0_darwin_amd64.tar.gz. That asset really exists on the v0.1.0 release, so nothing is broken — the file self-corrects at v0.2.0, when the release regenerates it. Hand-editing it is the thingCLAUDE.mdexplicitly forbids.