mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-10 02:25:56 +00:00
rcourtman
6351fd6526
Production telemetry (7d, 2026-07-17) shows a persistent tail of live installs on 6.0.0-rc.x and 6.0.3/6.0.4 while 6.0.5 has been stable since 2026-07-09. Root cause for the reachable stranding class: release selection trusted GitHub's created_at ordering, and this repo interleaves v5-line maintenance releases with v6 releases (v5.1.36 was created the day before v6.0.5). Whenever a v5.1.x release is the most recently created stable: - stable channel (getLatestReleaseForChannel) returned the first non-prerelease in list order -> "no update" for every v6 install until the next v6 release ships - the RSS rate-limit fallback returned the first feed entry matching the channel, same failure, both channels - the unattended updater trusted /releases/latest, which GitHub defines as most-recently-created stable -> timer no-ops in the same window All three now select the highest eligible version: the API path tracks newest stable + newest prerelease in one pass (prerelease = GitHub flag OR tag shape), the feed fallback picks the max matching the channel, and pulse-auto-update.sh scans /releases pairing each tag with its own draft/prerelease flags before the fail-closed shape filter, keeping /releases/latest as fallback. helm-chart-* tags fail semver parsing and are dropped everywhere. Verified not broken (pinned by new tests): rc-channel installs are offered the newer stable (6.0.0-rc.6 -> 6.0.5) and move onto the next rc line when one opens (-> 6.1.0-rc.2); the auto-update prerelease filter (fail-closed is_prerelease_tag, metadata-flag refusal) still refuses prerelease targets on stable. Go tests fail on the pre-fix code (returned 5.1.37 / "no update"). Contract: deployment-installability now pins version-max release selection with proofs in manager_stranded_upgrade_test.go and pulse_auto_update_test.go.