Do not assert that the version parameter pins MacPorts base

[jolierabideau]

Problem

CI on main fails, and has since 2026-08-25:

Run test "$(port version)" = 'Version: 2.12.5'
##[error]Process completed with exit code 1

Confirmed on unmodified main by dispatching the workflow there: run 34489699502. The breakage went unnoticed because the previous run on main was 2026-06-24.

Cause

The postflight script of the MacPorts package runs port -v selfupdate (portmgr/dmg/postflight.in):

echo "Synchronizing the MacPorts installation with the project's rsync server..."
if ! "${BINPATH}/port" -v selfupdate; then

selfupdate upgrades MacPorts base to the newest release. We install the pinned MacPorts-2.12.5-*.pkg — verified as the correct asset, 7,417,131 bytes — and the postflight then upgrades base to 2.12.6, released 2026-08-25.

So the version: parameter does not pin MacPorts base. It selects the package that bootstraps the installation; base then moves to whatever is current. The assertion only ever passed while the pinned version was the latest release, which was true from 2026-04-23 to 2026-08-25.

The postflight cannot be told to skip the selfupdate: update_macports is called on every exit path, and the same script also creates the macports run user and the default configuration files, so bypassing it wholesale would break the installation.

Change

• Validate installed MacPorts version now compares with a version sort, accepting a base that selfupdate moved forward while still failing on a base older than requested — so a genuinely broken install is still caught.
• README.md and action.yaml document version: for what it actually does, and the version output as the version requested rather than the one installed.
• The example workflow in the README no longer teaches the assertion that cannot hold; it just shows port version.

A plain string comparison would be wrong here — it makes 2.9.0 look newer than 2.12.5 — hence sort -V.

Verification

sort -V is available on macOS (sort 2.3-Apple). I ran the step's exact script under bash -e with a stubbed port:

Installed	Requested	Step
2.12.5	2.12.5	succeeds
2.12.6	2.12.5	succeeds (the case that is failing today)
2.13.0	2.12.5	succeeds
2.12.4	2.12.5	fails
2.9.0	2.12.5	fails (a string compare would wrongly pass)
2.12.10	2.12.9	succeeds

Both YAML files parse.

Note

This is the pre-existing failure that blocks #4. It is independent of that PR: the action step there succeeds, and only this assertion fails. Merging this should turn #4 green.

🤖 Generated with Claude Code

---

This change is