state: v0.1.2 is tagged and deployed but has no Forgejo release object #10

New issue

Closed

opened 2026-08-26 04:55:12 +00:00 by jlxq0 · 0 comments

jlxq0 commented

2026-08-26 04:55:12 +00:00

Owner

State, verified 2026-08-26

GET /repos/jlxq0/caldav-mcp/releases returns one entry, v0.1.1. The tag
list returns three:

tag	commit	release object	deployed
`v0.1.2`	`fc38a5f`	none	yes, production runs it
`v0.1.1`	`e1ad86b`	yes	beta runs it
`v0.1.0`	`d164d69`	none	no

Nothing is broken. The tag exists, CI built and pushed the image, and
caldav-mcp in fondue is serving v0.1.2 at
sha256:3d37a2ebe89851ae457f67e7fbb637d1f5d2948b177fa11da24f4d0b0f43c70c.
CHANGELOG.md carries a 0.1.2 - 2026-08-25 section with the RFC 8252 fix.

Why record it

The releases page is where someone looks to answer "did the loopback fix ship?"
and it currently answers no. That is a confident wrong answer produced from a
real page, and the correction takes a kubectl call that the person asking is
unlikely to make.

Two ways out, and this issue does not pick one:

Create the release object for v0.1.2 from the existing CHANGELOG.md
section, and decide whether v0.1.0 is worth backfilling.
Or accept that tags are the release record here and stop creating release
objects at all, so the page is consistently empty rather than selectively
populated. v0.1.1 having one and the others not is the part that misleads.

Either is fine. Half of one is what exists today.

## State, verified 2026-08-26 `GET /repos/jlxq0/caldav-mcp/releases` returns one entry, `v0.1.1`. The tag list returns three: | tag | commit | release object | deployed | |---|---|---|---| | `v0.1.2` | `fc38a5f` | **none** | yes, production runs it | | `v0.1.1` | `e1ad86b` | yes | beta runs it | | `v0.1.0` | `d164d69` | **none** | no | Nothing is broken. The tag exists, CI built and pushed the image, and `caldav-mcp` in `fondue` is serving `v0.1.2` at `sha256:3d37a2ebe89851ae457f67e7fbb637d1f5d2948b177fa11da24f4d0b0f43c70c`. `CHANGELOG.md` carries a `0.1.2 - 2026-08-25` section with the RFC 8252 fix. ## Why record it The releases page is where someone looks to answer "did the loopback fix ship?" and it currently answers no. That is a confident wrong answer produced from a real page, and the correction takes a `kubectl` call that the person asking is unlikely to make. Two ways out, and this issue does not pick one: - Create the release object for `v0.1.2` from the existing `CHANGELOG.md` section, and decide whether `v0.1.0` is worth backfilling. - Or accept that tags are the release record here and stop creating release objects at all, so the page is consistently empty rather than selectively populated. `v0.1.1` having one and the others not is the part that misleads. Either is fine. Half of one is what exists today.

jlxq0 referenced this issue

2026-08-26 05:25:57 +00:00

state: caldav-mcp-beta is running an image that predates the RFC 8252 loopback fix #9

jlxq0 referenced this issue from a commit

2026-08-26 06:48:48 +00:00

docs: make CHANGELOG the release record, not the releases page

jlxq0 referenced this issue from a pull request that will close it,

2026-08-26 06:49:10 +00:00

docs: make CHANGELOG the release record, not the releases page #14

jlxq0 closed this issue

2026-08-26 07:15:56 +00:00