Release notes software
Free Changelog Tool: Publish Release Notes on Your Listing
Every product listed on TechLogHub can publish versioned releases with release notes, right next to its feedback board and public roadmap. Users see what shipped, and the requests that led to it, on one page.
How the changelog works
- Versioned releases. Each release has a version, a type (major, minor or patch), a date and notes.
- On your listing. Releases show on your public product page, so visitors judging whether your product is maintained can see it is.
- Next to feedback. The same page carries your feedback board and roadmap — move a request to shipped and publish the release that delivered it.
- Managed from your dashboard. Create and edit releases under Dashboard → Releases once your product is listed or claimed.
How to write release notes people read
Lead with the effect, not the change.“Board loads 40% faster on large lists” tells a user why to care; “Added Redis cache for vote counters” tells them how you did it. Keep the implementation detail for the commit message.
Group by type. New, Improved, Fixed and Breaking is enough for almost every product. Readers scan for the group they care about — admins look for Breaking, everyone else for New.
Make breaking changes impossible to miss. Put them in their own group, say exactly what stops working, what to do instead, and the date the old behaviour ends.
Credit the request. If a change came from user feedback, say so. It shows the board is worth posting on, which is what keeps feedback coming.
Ship notes with the release, every time. A changelog last updated eight months ago reads as an abandoned product, even if you deploy daily. Short and regular beats long and rare.
Software release notes example
A minor release written to the rules above. Copy the structure; replace the content.
v2.4.0 — 6 November 2026 (minor) New - Bulk export: download any feedback view as CSV from the board's ⋯ menu. - Slack alerts now include the voter count, so you can triage without opening the app. Improved - Board loads ~40% faster on lists with 1,000+ requests (vote counts are now cached). Fixed - Dates in release emails used the server's timezone instead of the reader's. - Searching for a request with an apostrophe returned no results. Breaking - The /v1/feedback endpoint now paginates (50 per page). Pass ?page= to fetch more. Unpaginated responses stop on 1 December 2026.
Changelog and release notes FAQ
Common questions about publishing release notes
What is the difference between a changelog and release notes?
A changelog is the running, chronological record of every notable change across versions. Release notes are the entry for one version, written for the people affected by it. In practice a public changelog is a list of release notes, newest first, which is how releases appear on a TechLogHub listing.
Is the TechLogHub changelog free?
Yes. Listing a product is free and releases are part of the listing. You publish them from your dashboard and they appear on your product page alongside your feedback board and roadmap.
Which versioning scheme should I use?
Semantic versioning (MAJOR.MINOR.PATCH) is the default for software with an API or SDK: bump major for breaking changes, minor for new backwards-compatible features, patch for fixes. Date-based versions (2026.11) suit apps where users never pin a version. Pick one and stick to it — consistency matters more than the scheme.
Should release notes list every commit?
No. Commit logs are for contributors; release notes are for users. Group changes into New, Improved, Fixed and Breaking, describe the effect on the user rather than the implementation, and leave out internal refactors unless they change behaviour or performance.
Can I keep a CHANGELOG.md in my repo as well?
Yes, and for open-source projects you should — the Keep a Changelog format is the common convention. Your listing's releases can mirror the same entries for people who discover the project on TechLogHub rather than on GitHub.