Versions & releases

The lifecycle

1. Draft — a new list starts as a draft, visible only to you. Edits happen in place; drafts never create versions.
2. Publish — takes an immutable snapshot: version N. The list page always shows the current version; older versions remain browsable in Versions.
3. Edit again — editing a published list works on a working copy; the next publish produces version N+1 with a change note.

Change notes work like commit messages. You can write one yourself or let AI generate it from the diff between versions.

Releases

Versions are cheap and automatic; releases are deliberate. A release marks a specific version with a tag, a title and markdown notes — exactly like GitHub Releases. Use them to signal "this revision is the one to follow".

• Tag. Letters, digits, ., -, _, up to 40 characters — e.g. 1.2.0 or v1.2.0. Names like v3 (v plus digits only) are taken: git uses them for the versions themselves. A taken tag is never moved to another version — pick another one.

• From an agent. Releases can be published over MCP: create_release (two steps — a report first, then confirm: true), and list_releases shows the published ones. The tag also goes to the list's mirrors; deleting a release on the site does not remove the tag from git.

• Auto-notes. The "Generate from changes" button drafts notes from the diff of the chosen version against the previous release, with Added / Changed / Removed / Moved sections. Edit the text before publishing.

• Pre-release. The "Pre-release" checkbox marks a release as provisional: it does not get the "Latest" badge (the nearest ordinary release keeps it) and doesn't change the version's content — only its labeling.

• Assets. Each release offers the list as Markdown, HTML and a git bundle (.bundle), plus viewing its version and comparing with the previous.

• Atom feed. Public lists expose a release feed at /{owner}/{slug}/releases.atom — subscribe to follow new ones.

Under the hood: git

Every list is backed by a real git repository where each version is a commit touching list.json. That's why versions are immutable, diffable and cloneable — see Git access.