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 (default vN), a title and markdown notes — exactly like GitHub Releases. Use them to signal "this revision is the one to follow".

• 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.