Using Lunax

Roadmap & changelog

Both pages are generated automatically from your feedback posts. You never write them directly — you set a post's status, and the pages follow.

One status drives both pages

There is no roadmap editor and no changelog editor. Every entry on both pages is a feedback post, placed by its status alone.

Post status	Board	Roadmap	Changelog
Open	Yes	—	—
Planned	Yes	Planned column	—
In progress	Yes	In progress column	—
Done	Yes	Done column	Published
Declined	Yes	—	—

If you want something on the roadmap, it must be a post first

Internal work with no matching feedback post won't appear. Create a post for it yourself — staff can post to any board — then set the status. That's the intended way to put roadmap items in front of users.

The roadmap page

/b/{slug}/roadmap renders exactly three columns: Planned, In progress, and Done. The columns are fixed — they can't be renamed, reordered, or added to.

Within each column, posts are ordered by vote count, highest first.
There is no drag-and-drop and no manual ordering — voting is the only lever.
Open and Declined posts never appear here.
Each card links back to the full post, so users can vote and comment.
The page is public, and it has no item limit.

The changelog page

/b/{slug}/changelog lists every post marked Done, most recently updated first, capped at 50 entries. Each entry shows a date, the post title as a link, and the first couple of lines of its description.

The date is last-modified, not a ship date

The date shown is when the post was last changed — not when you shipped it. Editing a Done post later, for any reason, moves it back to the top of the changelog with a new date. Set the status to Done as the final action of a release, and avoid touching old entries.

The description is what your users read as release notes, so write it for them. If a post arrived as “pls add dark mode!!”, rewrite the description before marking it Done.

A release workflow that works

Triage new posts weekly. Everything you intend to build goes to Planned.
When an engineer picks it up, flip it to In progress. Voters see it move and stop asking.
Before you ship, rewrite the post description as a short release note — what changed, from the user's point of view.
On release day, set Done. It leaves the In progress column and appears at the top of the changelog in one move.
Comment on the post to tell voters it's live. They get no email, so the comment is the only signal you have.

Feedback posts never send email

Nothing on a board notifies anyone — not a status change, not a comment, not a reply to your idea. Only tickets send mail. Users discover updates by revisiting the board, so a changelog that reads well is doing real work.

Limits and gotchas

Changelog shows the latest 50 Done posts; older entries drop off with no archive.
No versions, tags, or release grouping — entries are a flat, dated list.
No scheduled or draft publishing. Setting Done publishes instantly.
No RSS feed or email digest for either page.
Moving a post off Done silently removes it from the changelog.
Both pages inherit the app's privacy — a private app hides both from the public.

Feedback boards

Posting, voting, comments, and moderation

Apps

Slugs, logos, and board privacy

Widget integration

Surface the roadmap inside your product

Docs overview

Back to the start