A changelog widget inside your app earns its place by notifying users of updates without anybody writing them twice. Release notes die because they are a second job. Somebody ships something, and then somebody has to remember to write it down somewhere else, and after about six weeks nobody does.
This widget reads the board you already run. A card that reaches your Completed column is what a release note is made of, so the changelog is a view of work you have already tracked rather than a document you maintain.
What does the widget actually draw?
A dated timeline, newest first, with a show more button at the bottom rather than pagination.
Five releases arrive at a time and the button fetches the next five, hiding itself once there are none left. An empty changelog says it is empty rather than drawing a blank space, which matters on the day you install it and have not published anything yet.
The date is a real time element carrying a machine readable timestamp beside the words a person reads, so anything parsing your page gets the date rather than having to guess at your format.
It goes in a container on your own page, styled by your own theme values, so it looks like part of your product instead of like somebody else's product in a box.
The embed key comes from a board, so a trial is 14 days with a card at signup and the snippet works as soon as you have one.
What is the line you paste?
The same two tags every widget uses, and one call.
<link rel="stylesheet" href="https://app.votefirst.app/embed/votefirst.css">
<script src="https://app.votefirst.app/embed/votefirst.js"></script>
<script>
VoteFirst.init({ project: 'your-project-slug', key: 'your-embed-key' });
VoteFirst.changelog('#votefirst-changelog');
</script>
<div id="votefirst-changelog"></div>
The script tag can carry the two values itself as data-project and data-key, which saves the init call entirely. Either way the elements land in your own document rather than in a frame, so your stylesheet and your developer tools reach all of it.
The install in three steps is written out in the quickstart, and the appearance the widget inherits is documented separately.
What is inside one release entry?
The release name, whatever you wrote, and then the list of what actually shipped in it.
That last part is the bit worth reading twice, because it is the thing this widget does that a changelog tool cannot. Every feature in the release is listed by name, and beside each one is how many people asked for it.
A changelog that says we added scheduled exports is an announcement. A changelog that says we added scheduled exports, requested by 34 people, is an answer, and the only reason we can draw the second is that the same board holds the votes and the release.
Nothing had to be copied across for that number to be there.
Each shipped item can also carry a type, drawn as a small label beside it. New, improvement, fix, bug fix, breaking change and security are the ones with names, so a reader scanning the entry can find the breaking change without reading the prose.
If you have chosen to hide vote counts on your board, the requested by line goes with them. The widget does not have a second opinion about that, it reads the same setting.
Can I make one release stand out?
Yes. A release can be marked featured, and the widget draws it differently.
The dot on the timeline changes, the card carries its own class, and a small badge sits at the top of it. That is for the release you want somebody scrolling past to actually stop at, which on most changelogs is one entry in twenty rather than none.
Who gets told when I publish a release?
Signed in voters whose own vote is in that release. That is the whole list.
This is the most important sentence on the page and it is a limit rather than a feature, so it goes near the top instead of in a footnote.
If you publish a release containing three features, the email goes to the people who voted for those three features and who have an account. It is not a general announcement to a subscriber list, because there is no subscriber list.
The thinking behind it is that the person who asked for a thing is the person who wants to hear it shipped, and that a changelog email to somebody who never asked for anything is the kind of message that teaches people to ignore you.
Whether you agree with that is a fair question, and either way you should know which one you are buying.
Is there an RSS feed?
No. There is no feed of any kind, and we are not going to imply otherwise by calling it something else.
If a feed is how your users follow releases, several tools in this category publish one and we have written down which. It is a real gap and it is on the list of things to decide rather than something we have quietly ruled out.
Does the changelog build itself from the shipped cards?
The content comes from your board, and the release is still something you write.
Reaching the Completed column is what makes a card eligible. It does not generate prose for you, and nothing on our side drafts release notes. If automatic drafting is what you want, at least one tool in this category does it and we do not.
So the honest description is that the widget removes the copying rather than the writing.
14 days, a card at signup, then $9 or $39 a month.
Does it work if the visitor is signed out?
Yes. Reading a changelog needs no account at all, and neither does anything else the widgets do.
A signed out visitor who votes or comments gets an anonymous identity minted in their own browser's storage. No cookies, and nothing is sent with credentials.
What does it cost?
Nothing beyond your plan. No widget is held back for the higher plan, so the changelog widget works on the nine dollar plan.
Comments switch off on the embed if the account behind it lapses, which is the one thing that changes.
How do I install it?
One script tag with your project and your public key, and a container where you want the timeline. That is the whole of it, and it initialises itself.
If you would rather control when it appears, load the stylesheet and the script and call the setup yourself. Calls made before the script finishes loading queue instead of failing.
There is a pinned version address cached for a year if you want one exact build rather than the current one.
Can I style it or read it from my own code?
Yes, past the theme values, because the markup is built to be reached.
Every release is an article carrying its own release id. Every shipped item carries its feature id and, where it has one, its change type.
So a stylesheet that wants security notes in red, or a script that wants to scroll to one specific release, has something to hold on to without us shipping a setting for it.
One note for anyone whose security review will ask. The release body is the single place this widget inserts markup, and that markup is produced by a renderer running its defaults, which refuse raw HTML outright and blank out dangerous link schemes.
If you would rather it inserted nothing at all, there is an option that turns it off and prints the release body as plain text.
The widget suits a product whose readers are already inside a page you control. A team whose readers arrive from search wants the hosted changelog page instead, because a page has its own address and an embed does not.
The two things worth knowing before you commit
The email goes to voters in the release, not to a subscriber list. And there is no feed.
Both of those are on this page rather than discovered later, because a changelog is a promise to keep people informed and you should know exactly which people before you make it.
