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

Merged

jlxq0 merged 1 commit from docs-release-record into main

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

jlxq0 commented

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

Owner

Closes #10.

The measurement first

Nothing downstream reads the Forgejo release object:

Renovate tracks the container registry — the platform manifest annotation is
datasource=docker packageName=forge.oddie.app/jlxq0/caldav-mcp.
ArgoCD reads the digest pinned in that manifest.
CI triggers on push of v* tags, and creates no release.

So it is human-facing only, which is where a half-populated record does its
damage rather than none.

The convention, checked rather than assumed

repo	tags	release objects	latest
`matrix-mcp`	50	0	—
`jmap-mcp`	14	1	`v0.1.0`
`typst-mcp`	11	0	—
`m365-mcp`	8	0	—
`hevy-mcp`	4	0	—
`carddav-mcp`	4	1	`v0.1.2`
`caldav-mcp`	4	1	`v0.1.1`

Four of seven have never had one. The three that do have exactly one, each an
early version that was never continued — jmap-mcp has fourteen tags and a
release object for its first. Nobody maintains these anywhere, and backfilling
v0.1.2 here would create an expectation that the evidence says will not hold
past the next release.

What changed

CHANGELOG.md's header claimed release notes are published with each signed
tag. They are not, and that claim is what makes the empty page read as an
answer. It now says this file and the tags are the record, and that a missing
release object says nothing about whether a version shipped. The same is in
AGENTS.md under Known Pitfalls, with the reason, so the next agent does not
helpfully create one.

The v0.1.1 release object's body carried verification detail that existed
nowhere else — the Rust 1.98 gate results and the pre- and post-promotion
acceptance run. That is now a ### Verified section under 0.1.1, so nothing
is lost when the object goes.

After this merges

I will delete the v0.1.1 release object, so the page is consistently empty
rather than selectively populated. It is recreatable from this file if anyone
disagrees, which is the point of moving the content first.

Closes #10. ## The measurement first Nothing downstream reads the Forgejo release object: - Renovate tracks the container registry — the platform manifest annotation is `datasource=docker packageName=forge.oddie.app/jlxq0/caldav-mcp`. - ArgoCD reads the digest pinned in that manifest. - CI triggers on `push` of `v*` tags, and creates no release. So it is human-facing only, which is where a half-populated record does its damage rather than none. ## The convention, checked rather than assumed | repo | tags | release objects | latest | |---|---|---|---| | `matrix-mcp` | 50 | **0** | — | | `jmap-mcp` | 14 | 1 | `v0.1.0` | | `typst-mcp` | 11 | **0** | — | | `m365-mcp` | 8 | **0** | — | | `hevy-mcp` | 4 | **0** | — | | `carddav-mcp` | 4 | 1 | `v0.1.2` | | `caldav-mcp` | 4 | 1 | `v0.1.1` | Four of seven have never had one. The three that do have exactly one, each an early version that was never continued — `jmap-mcp` has fourteen tags and a release object for its first. Nobody maintains these anywhere, and backfilling `v0.1.2` here would create an expectation that the evidence says will not hold past the next release. ## What changed `CHANGELOG.md`'s header claimed release notes are published with each signed tag. They are not, and that claim is what makes the empty page read as an answer. It now says this file and the tags are the record, and that a missing release object says nothing about whether a version shipped. The same is in `AGENTS.md` under Known Pitfalls, with the reason, so the next agent does not helpfully create one. The `v0.1.1` release object's body carried verification detail that existed nowhere else — the Rust 1.98 gate results and the pre- and post-promotion acceptance run. That is now a `### Verified` section under `0.1.1`, so nothing is lost when the object goes. ## After this merges I will delete the `v0.1.1` release object, so the page is consistently empty rather than selectively populated. It is recreatable from this file if anyone disagrees, which is the point of moving the content first.

jlxq0 added 1 commit

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

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

CI / cargo (pull_request) Successful in 44s

Details

CI / docker (pull_request) Successful in 1m3s

Details

cd6caf7f6a

The header claimed release notes are published with each signed tag. They are
not: v0.1.1 has a Forgejo release object, v0.1.0 and v0.1.2 do not, and v0.1.2
is what production runs. Someone checking whether the RFC 8252 loopback fix
shipped reads that page and concludes it did not.

Nothing downstream reads the release object. Renovate tracks the container
registry (datasource=docker), ArgoCD reads the digest pinned in the platform
manifest, and CI triggers on the tag. It is human-facing only, which is exactly
where a half-populated record does its damage.

Four of the seven Rust MCP servers have never had a release object and the three
that do stopped after their first, so this is the house convention rather than a
gap in this repo. Record it instead of backfilling something nobody maintains.

The v0.1.1 object's body carried verification detail that existed nowhere else;
it is now a Verified section under 0.1.1 so the object is redundant.

Closes #10

jlxq0 merged commit c0e32d7d14 into main

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

jlxq0 deleted branch docs-release-record

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

jlxq0 referenced this pull request from a commit

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

Merge pull request 'docs: make CHANGELOG the release record, not the releases page' (#14) from docs-release-record into main