A fix reached panels only with the next release, and a release is a
ceremony: a version bump, a changelog, a translation pass, a release PR.
A patch build is the release with the fixes made since, published as
X.Y.Z-pN by one run of the new Build Patch workflow from any ref: it picks
the release the ref contains, numbers the patch, runs the unit tests, stamps
the version into the build (as a nightly's is), builds the files a release
has and publishes them on the channel of the release it patches. Nothing is
prepared by hand.
The panel takes it as it takes a release, on MAIN and on load balancers:
- version_compare() already orders 2.6.5 < 2.6.5-p1 < 2.6.6. The release
list is now ordered by version on every channel, not by publication: a
patch of an older release is published after the release that follows it
and must not hide it.
- An update, a pin and a rollback accept a patch version.
- A patch's changelog is read from its own asset.
- A module that asks for core X.Y.Z keeps loading on X.Y.Z-pN.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AneTzAHPPkYWPQjwyZ2td9
The list MAIN's update leaves now holds every load balancer with when
it was told, and cron:servers (every ten minutes) drops one only once
its row shows MAIN's release. One that is back is told when it never
was, when its update could not be queued, or when the update expired
(a day) while the node was away: before, a failed queue or a node that
dropped off just before the tell left the list untold.
The fanout binary check runs every ten minutes, not hourly, while the
daemon is wanted and not there yet: with its stamp kept for the hour,
a node on which fanout was just switched on waited that long for it.
- MAIN's update lists the load balancers it could not tell (offline
then) and cron:servers tells each one once, when it is back and still
behind. The hourly re-send by version alone undid an admin's rollback
of one load balancer within the hour.
- cron:tmp no longer sweeps state with the leftovers: the root cron's
hourly and daily stamps (fanout_binary, xcvm_core, ytdlp, ffmpeg), so
each check stops running, and asking GitHub, every ~11 minutes on
every node; and the updater's archive, which post-update reads again
after the chown of the whole tree.
- the updater, after a failed copy, still gives the tree back to xc_vm
and checks nginx.conf before it stops: cp re-owns the directories it
did reach, and the service started on a tree xc_vm could not enter.
When nothing was copied, the archive goes before the post-update that
puts the server back online, so it installs nothing from it.
- install (and reinstall) takes MAIN's own release, not the newest one;
a release without the archive or its hash stops it cleanly (status 4)
instead of a TypeError that left the server installing forever
- an unsupported system, or binaries GitHub could not provide, stops the
install: the archive carries no PHP or nginx
- the OS version falls back to os-release (minimal Debian has no
lsb_release); no MaxMind PPA, which nothing installs from; no
status run as xc_vm, which status refuses
- an update run on a load balancer without MAIN's release takes the one
MAIN's row records, never the newest
- MAIN tells load balancers still on an older release to update every
hour (auto_update_lbs), so one offline during MAIN's update follows
- the updater stops on a failed extract or copy, puts the server back
online when nothing was copied, and always starts the service again
NodeActions::update names MAIN's XC_VM_VERSION to the node, but
UpdateCommand::pinned() accepted only x.y.z, so a dev build (x.y.z-dev.N)
was dropped and the LB fell back to its own channel lookup instead of
MAIN's build. Accept nightly tags too; assetUrl() already routes them to
the dev repository.
