Release notes are useful only when customers can find them, scan them, and understand what changed. We gave Popup Maker’s release history a dedicated public home—and kept GitHub as the source our developers already use.
The problem with release notes that live everywhere
Popup Maker has been shipping for years. That history existed, but it was spread across product releases and developer-facing sources. A customer looking for a fix or trying to understand the pace of development had to know where to look first.
That also made support harder than it needed to be. There was no single, durable URL we could point to when someone asked, “What changed?”
What we changed
We created a dedicated Popup Maker changelog inside WordPress. At publication, it surfaces 129 dated releases across Popup Maker Core, Popup Maker Pro, Ecommerce Popups, and LMS Popups.
- Product filters separate Core, Pro, Ecommerce, and LMS updates.
- Change-type filters make features, fixes, improvements, maintenance, and security work easier to scan.
- Year filters turn a long release history into something customers can browse.
- Individual release pages give support and customers stable links to the details that matter.
How the ongoing workflow is designed
We still write release evidence where development happens: GitHub. The WordPress layer is the customer-facing review and publishing surface.
GitHub Release → signed delivery → protected WordPress draft → editorial review → publish
The protected draft matters. Automation can move the source notes into WordPress without deciding what customers should see. We can publish the notes as-is, or add context, screenshots, and clearer explanations before they go public.
We used the product’s backfill path to give the archive useful history immediately. The release-triggered workflows are configured for future releases, and we’ll use the next normal release as the first full end-to-end operational proof.
What we gained
One customer-facing source of truth
Customers and support now have one public destination for release history instead of a trail of scattered links.
History that is useful on day one
A changelog with only the newest release feels empty. Backfilling the archive made the page useful immediately and showed the depth of work already shipped.
A safer handoff from engineering to customers
The draft checkpoint lets engineering preserve exact release evidence while product and support improve the explanation. Automation handles transport; a person still owns publication.
A changelog that belongs to the product
The archive lives on our site, uses our design, and can evolve with our content. GitHub remains excellent for developers; WordPress gives customers a better front door.
The practical lesson
A public changelog is not just an announcement feed. It is product documentation, support evidence, and a visible record that the software is still being improved.
If your team already publishes GitHub Releases, the most valuable change may be keeping that workflow and adding a reviewable customer layer—rather than asking developers to maintain the same notes twice.
See it for yourself
Browse the real Popup Maker archive, then open a working sandbox if you want to inspect the GitHub-to-WordPress workflow behind it.
