The changelog and its feed
Changes are published at /changelog/ as an ordinary page and syndicated as Atom at /changelog/feed.xml. An entry carries a date, a version, a title, a summary, a list of changes, and optionally what you need to do and what is still not possible. Atom was chosen over RSS for unambiguous dates and a content model that needs no encoding guess.
Three ways to read it#
| Route | Returns |
|---|---|
/changelog/ | The HTML page — one section per entry, newest first |
/changelog/index.md | The Markdown alternate, like any other page |
/changelog/feed.xml | The Atom feed |
GET /api/public/docs/page?ref=/changelog/ | The page record with the Markdown body |
MCP get_changelog | The same record through the same function |
The changelog is a page in the corpus rather than a special case: it has an id, it enters the sitemap, it mirrors to Markdown and it is searchable. That is why the same fetch routes work on it as on anything else, and why it carries the corpus's updated discipline.
What an entry contains#
date- The release date. An entry that has not shipped carries no date and is rendered as *Unreleased*.
version- The product version the entry belongs to.
title- A short name for the change.
summary- One paragraph, in the same register as the rest of the corpus.
changes- The list of individual changes, rendered as bullets in the feed's content.
action- Optional. What you need to do — appended to the feed content as *What you need to do:*.
limits- Optional. What is still not possible — appended as *Still not possible:*.
The last two are the ones worth building around. A changelog that lists only additions leaves a reader to work out whether anything is required of them and whether the thing they were waiting for arrived; action and limits answer both in the entry rather than in a support conversation.
The Atom document#
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Connect by JBRH — changelog</title>
<link href="https://connectbyjbrh.com/changelog/"/>
<link rel="self" href="https://connectbyjbrh.com/changelog/feed.xml"/>
<entry>
<title>…</title>
<id>tag:connectbyjbrh.com,2026-09-10:changelog-0</id>
<link href="https://connectbyjbrh.com/changelog/"/>
<updated>2026-09-10T00:00:00Z</updated>
<summary>…</summary>
<content type="text">…summary, then one line per change…</content>
</entry>
</feed>Atom rather than RSS is a deliberate choice: its date handling is unambiguous, and its content model does not require a reader to guess an encoding. <updated> is the entry's date at midnight UTC, so entries are day-granular — two changes released on the same day share a timestamp and must be ordered by something else if order matters to you.
Two quirks worth knowing before you build on it#
Every entry links to the same page. There is no per-entry anchor in the feed: each <link> points at /changelog/. A reader offering "open original" will always land at the top of the changelog rather than at the item, which is a limitation of the feed rather than of the reader.
For a machine that only needs to know *whether* something changed, the feed is heavier than necessary. The version and generated pair at the top of /docs-manifest.json moves on every rebuild and costs one small fetch — poll that, and read the changelog when it moves.
Questions#
Is there an RSS version?
No. One feed is published, and it is Atom. A reader that handles RSS almost always handles Atom; the reverse is less reliably true, which is part of why the choice went this way.
Does an unreleased entry appear in the feed?
It appears with the corpus verification date standing in for its missing release date, and the page renders it as *Unreleased*. Do not treat a feed <updated> value as proof that something shipped that day — the page is clearer about that than the feed can be.
How often is the changelog regenerated?
On a deploy, with the rest of the corpus. There is no incremental publication path, which is why the manifest's build stamp is a reliable signal that anything at all has changed.