Forgejo: stay on 15.0 LTS, plan the 19.0 migration for ~April 2027 #11

New issue

Open

opened 2026-08-26 14:42:25 +09:00 by floot · 0 comments

floot commented

2026-08-26 14:42:25 +09:00

Owner

Recording a decision so the version gap is not mistaken for drift, and so the
migration window is not missed.

Decision: stay on LTS

The host runs Forgejo 15.0.6; current is 16.0.3. That gap is intended.

15.0 is the LTS line, supported to 2027-07-15.
16.0 is non-LTS and goes EOL 2026-10-29 — about two months from now.
"Catching up to main" would move a supported install onto an unsupported one
and force another migration immediately.

The reasoning is already in flake.nix, along with two traps worth repeating:

services.forgejo.package defaults to pkgs.forgejo-lts, so the overlay
overrides forgejo-lts. Overriding forgejo instead builds fine and changes
nothing — a no-op that looks like a successful upgrade.
Forgejo runs one-way database migrations on the first start of a new
major. The health-check auto-rollback does NOT cover this: a rollback
restores the old binary against an already-migrated database. Back up
/var/lib/forgejo before any version bump.

When the next LTS lands

From the release history on Codeberg, majors ship quarterly, mid-month:

major	released
13.0	2025-10-16
14.0	2026-01-15
15.0	2026-04-16
16.0	2026-07-16

So 17.0 ≈ mid-October 2026, 18.0 ≈ mid-January 2027, 19.0 ≈ mid-April 2027.

LTS appears to be every fourth major — 11.0 was the previous one (window closed
2026-07-16) and 15.0 is the current one — which makes 19.0 the next LTS.

Caveat: that is inferred from the release cadence and the two known LTS
windows, not read from a support-policy announcement. Worth confirming against
Forgejo's own policy page nearer the time.

The plan

If the pattern holds there is roughly a three-month overlap — 19.0 in April,
15.0 supported until July — so the migration can be done deliberately:

Confirm 19.0 is actually designated LTS.
Back up /var/lib/forgejo. This is the step the deploy safety net cannot
do for us.
Point the nixpkgs-forgejo input at a revision carrying 19.0 and override
forgejo-lts (not forgejo).
Apply, and verify by reading the version back from /api/v1/version rather
than by the build succeeding — see the no-op trap above.

Two majors of migrations in one jump, still one-way.

Recording a decision so the version gap is not mistaken for drift, and so the migration window is not missed. ## Decision: stay on LTS The host runs **Forgejo 15.0.6**; current is 16.0.3. That gap is intended. - 15.0 is the LTS line, supported to **2027-07-15**. - 16.0 is non-LTS and goes EOL **2026-10-29** — about two months from now. "Catching up to main" would move a supported install onto an unsupported one and force another migration immediately. The reasoning is already in `flake.nix`, along with two traps worth repeating: - `services.forgejo.package` defaults to `pkgs.forgejo-lts`, so the overlay overrides `forgejo-lts`. Overriding `forgejo` instead builds fine and changes nothing — a no-op that looks like a successful upgrade. - Forgejo runs **one-way database migrations** on the first start of a new major. The health-check auto-rollback does NOT cover this: a rollback restores the old binary against an already-migrated database. Back up `/var/lib/forgejo` before any version bump. ## When the next LTS lands From the release history on Codeberg, majors ship quarterly, mid-month: | major | released | | --- | --- | | 13.0 | 2025-10-16 | | 14.0 | 2026-01-15 | | 15.0 | 2026-04-16 | | 16.0 | 2026-07-16 | So 17.0 ≈ mid-October 2026, 18.0 ≈ mid-January 2027, **19.0 ≈ mid-April 2027**. LTS appears to be every fourth major — 11.0 was the previous one (window closed 2026-07-16) and 15.0 is the current one — which makes **19.0 the next LTS**. Caveat: that is inferred from the release cadence and the two known LTS windows, not read from a support-policy announcement. Worth confirming against Forgejo's own policy page nearer the time. ## The plan If the pattern holds there is roughly a three-month overlap — 19.0 in April, 15.0 supported until July — so the migration can be done deliberately: 1. Confirm 19.0 is actually designated LTS. 2. Back up `/var/lib/forgejo`. This is the step the deploy safety net cannot do for us. 3. Point the `nixpkgs-forgejo` input at a revision carrying 19.0 and override `forgejo-lts` (not `forgejo`). 4. Apply, and verify by reading the version back from `/api/v1/version` rather than by the build succeeding — see the no-op trap above. Two majors of migrations in one jump, still one-way.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

floot/endo#11

No description provided.

Rows
Columns