Release assets of the same version embed different Mercure versions (static: v1.0.2, Windows: v0.24.2) #2685

What happened?

The binaries attached to the same release (v1.12.7) embed different major versions of Mercure depending on the platform, and the content of the static binaries changes over time without a new release.

How to check:

# Linux / macOS assets (no need to run them)
$ go version -m frankenphp-linux-x86_64 | grep 'dunglas/mercure\s'
	dep	github.com/dunglas/mercure	v1.0.2
# Windows asset
> frankenphp.exe build-info | findstr dunglas/mercure
dep	github.com/dunglas/mercure	v0.24.2

Mercure 1.0 changes the Caddyfile syntax (publisher_jwt/subscriber_jwt → issuer { publisher { jwt … } subscriber { jwt … } }, compatibility level) and the JWT format. As a result:

• the same Caddyfile does not work on all platforms of the same release: a config written for Mercure 1.0 is silently ignored by the Windows binary (issuer/resource_identifier not understood), and the legacy config fails on the Linux/macOS binaries;
• a working Linux setup that downloads releases/latest/download/frankenphp-linux-* broke overnight without any version change, when the nightly rebuild picked up Mercure 1.0. We had to pin an older tag to recover.

Cause

1. Unversioned module in the static build. build-static.sh L209 passes --with github.com/dunglas/mercure/caddy to xcaddy without a version, so every build resolves the latest Mercure. The Windows build (windows.yaml) runs go build with caddy/go.mod, which pins v0.24.2.
2. Nightly in-place rebuild of a published release. Both static.yaml and windows.yaml rebuild the latest tag on a schedule and upload with --clobber. Combined with (1), the dependencies of an already published release change over time.

This was already noticed by @henderkes in #2611 (comment) (2026-09-25: "building FrankenPHP right now already pulls in Mercure v1.0.0, without a new release") and in #2674, but as far as I can tell no issue tracks the impact on the official release assets.

Suggested fix

• In build-static.sh, pin the xcaddy modules to the versions declared in caddy/go.mod (e.g. --with github.com/dunglas/mercure/caddy@$(go list -m -f '{{.Version}}' github.com/dunglas/mercure/caddy) run from caddy/), so all platforms of a release ship the same dependencies.
• If the scheduled rebuilds are meant to pick up PHP security updates, keep the Go dependencies of a published tag fixed (or publish the rebuilt binaries as a new patch release), so that releases/latest/download/… does not change behaviour silently.

Once a release containing #2611 is published, the Windows build will also ship Mercure 1.0, which removes the current mismatch. However, the root cause (unpinned modules + in-place rebuilds) can cause the same problem again with the next major update of any of these modules.

Build Type

Static binary

Worker Mode

No

Operating System

Other (tell us more in the description)

Affects the official release assets for GNU/Linux, macOS and Windows (compared with each other).

CPU Architecture

x86_64

PHP configuration

Relevant log output

# Same Caddyfile (Mercure 1.0 syntax), same release v1.12.7:
# - frankenphp-linux-x86_64 / frankenphp-mac-arm64: hub works as expected
# - frankenphp-windows-x86_64: starts without errors, but `issuer` /
#   `resource_identifier` are silently ignored