CI: leave :latest to the newest series once 27.1 ships (release/2026) #240

Merged

jcoffey-dev merged 1 commits from ci/latest-follows-the-newest-series into release/2026

2026-10-29 19:02:59 +00:00

jcoffey-dev commented

2026-10-29 18:53:33 +00:00

Owner

A 2026.x release from this branch moves :latest, GHCR's :latest and the GitHub "latest release" on every tag. That is right while 2026.x is the newest series. Once 27.1 ships it would be wrong: a 2026.x security release after it would take :latest back to the older line. (GATE-27.1: "Before 27.1 ships: release/2026's publish workflows still move :latest".)

The version job (GitHub build and Gitea publish both) now asks Gitea for the newest 50 final releases. It moves :latest only while none of them is numbered by series (v27.1, v27.1.3). The switch therefore happens on its own when 27.1 is published, with nothing to change on release day. Covered:

the registry index;
the GHCR copy;
the GitHub release copy (--latest=false);
the release body, which says which way it went.

The check fails rather than guess: a wrong :latest is worse than a re-run.

Checked:

the jq filter against the live API (no series release yet, so :latest moves) and against a list with v27.1 in it (it holds);
the Gitea-side Python against the internal API (latest=true today);
both workflow files parse.

This branch only. Main's own workflows already treat RCs as pre-releases.

A 2026.x release from this branch moves `:latest`, GHCR's `:latest` and the GitHub "latest release" on every tag. That is right while 2026.x is the newest series. Once 27.1 ships it would be wrong: a 2026.x security release after it would take `:latest` back to the older line. (GATE-27.1: "Before 27.1 ships: release/2026's publish workflows still move `:latest`".) The `version` job (GitHub build and Gitea publish both) now asks Gitea for the newest 50 final releases. It moves `:latest` only while none of them is numbered by series (`v27.1`, `v27.1.3`). The switch therefore happens on its own when 27.1 is published, with nothing to change on release day. Covered: - the registry index; - the GHCR copy; - the GitHub release copy (`--latest=false`); - the release body, which says which way it went. The check fails rather than guess: a wrong `:latest` is worse than a re-run. Checked: - the jq filter against the live API (no series release yet, so `:latest` moves) and against a list with `v27.1` in it (it holds); - the Gitea-side Python against the internal API (`latest=true` today); - both workflow files parse. This branch only. Main's own workflows already treat RCs as pre-releases.

jcoffey-dev added 1 commit 2026-10-29 18:53:33 +00:00

CI: leave :latest to the newest series once 27.1 ships

ci / fork-checks (pull_request) Skipped

Details

ci / build (pull_request) Skipped

Details

github/ci (branch) GitHub Actions

Details

ci / github (pull_request) Successful in 8m25s

Details

dfff9c7cdf

A 2026.x release from this branch moved :latest, GHCR's :latest and the
GitHub "latest release" on every tag. That is right while 2026.x is the
newest series, and wrong once 27.1 ships: a 2026.x security release
after it would take :latest back to the older line.

The version job now asks Gitea for the newest final releases and moves
:latest only while none is numbered by series (v27.1, v27.1.3), so the
switch happens on its own when 27.1 is published, with nothing to
change on release day. The release body says which way it went. The
check fails rather than guess: a wrong :latest is worse than a re-run.

Checked against the live API (no series release yet, :latest moves) and
against a list with v27.1 in it (it holds). Both workflow files parse.

jcoffey-dev merged commit c887e83bae into release/2026

2026-10-29 19:02:59 +00:00

jcoffey-dev deleted branch ci/latest-follows-the-newest-series

2026-10-29 19:02:59 +00:00

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: inbuxa/inbuxa-server#240