Every tool listing on directree has a Recent updates section that pulls dated entries from the product's GitHub releases or changelog feed. Sixty listings are connected and 371 entries have come through, which is enough to see what SaaS teams actually do with a changelog, as opposed to what the guides say they should do. The numbers below were pulled from that table on 7 September 2026.
Changelog vs release notes
A changelog is the running, dated list of what changed in a product, one line per change, newest first. Release notes are the longer write-up for a single release. A good changelog links each entry to its release notes; a good release note starts with the one line that will appear in the changelog.
Where SaaS teams publish changelogs
| Where the entry lives | Entries | Share |
|---|---|---|
| GitHub release | 266 | 72 percent |
| A changelog or release-notes page on the product's own site | 65 | 18 percent |
| A blog post | 20 | 5 percent |
| Somewhere else (docs, forum, social) | 20 | 5 percent |
Of the 60 connected sources, 48 are GitHub repositories and 6 are RSS or Atom feeds. Developer tools dominate the connected set, which skews the numbers toward GitHub, but the pattern holds beyond them: teams that publish releases on GitHub keep a changelog by default, because the platform forces a date, a title and a URL on every release. Teams with a marketing-site changelog page keep one only if somebody owns it.
How often teams ship
- Median gap between entries, across the 23 products with three or more dated entries: 3.6 days.
- Entries in the last 30 days: 151. In the last 90 days: 259.
- Every connected product with at least one entry has shipped something in 2026.
The "monthly changelog" convention from the SaaS playbooks does not match what shipping teams do. The products in this set publish several times a week and let the changelog be the record. What they do not do is batch three weeks of work into one "improvements and fixes" post.
How teams name releases
- 272 of 371 entry titles (73 percent) contain a version number.
- Only 14 (4 percent) start with a verb such as "Added" or "Fixed".
- 9 contain a year.
- The median title is 2 words and 18 characters, which usually means "v2.4.1" and nothing else.
That last number is the problem. A version number is a fact, but it is not information. "v2.4.1" tells a buyer, a crawler or an AI assistant nothing about what changed. The entries that read well on a listing, in a feed and in an answer engine are the ones that name the change: "v2.4: SSO for Okta and Google Workspace".
The seven practices that make a changelog usable
- Name the change, not the version. Put the version first if you must, then a colon, then what shipped. One line, under 80 characters.
- Date every entry. GitHub does this for you. On your own site, print the date in the entry and in the feed.
- Publish releases, not tags. A tag has no notes and no readable date. A release has both, and every aggregator, including ours, reads releases only.
- Keep one changelog per product. If your changelog feed is really your marketing blog, connect the changelog. Funding rounds and feature-marketing posts are not product changes.
- Link each entry to its release notes. The changelog line is the headline; the notes hold the detail, the screenshots and the migration steps.
- Ship the entry with the change. Backfilling a month later produces the batched "minor improvements" entries that nobody reads and nobody cites.
- Expose it as a feed. An Atom or RSS feed, or GitHub releases, lets directories, status pages and assistants pick up the entry without anyone copying it.
A changelog entry template
2026-09-07 v2.4: SSO for Okta and Google Workspace
Admins can enforce SSO per workspace. Existing password logins keep working until you turn enforcement on.
Release notes: the release page on GitHub or your changelog
Three parts: an ISO date, a headline that names the change, and a link. The second line is optional and stays under 200 characters. That is also the format a founder post takes on a directree listing.
Why a changelog helps a listing in search and in AI answers
A directory listing is a stable URL. A dated entry arriving every few days changes that URL for a reason: the page content is different, the sitemap's last-modified date moves only when something real landed, and the crawler comes back. We run a quality gate over every listing each night, and only listings with enough real content are allowed into the index. A maintained changelog counts toward that, because two dated entries in the last six months prove that somebody is still shipping in a way no description can.
When someone asks an assistant whether a tool supports a feature, or how recently it was updated, the assistant wants a dated fact with a source. A changelog entry is a date, a specific claim and a link to the release. We expose the same entries in each listing's machine-readable facts file with their provenance, so an answer engine can quote "added SSO on September 3, according to the project's own release" instead of guessing from a description written months ago. The Appwrite listing shows what that looks like with real release titles.
How the directree changelog works
Every listing shows the five newest entries on the listing page, never as a separate URL. Each entry is a date, a headline, a link back to the source, and the same provenance badge used everywhere else on the site. Entries come from GitHub releases (pre-releases excluded), from a connected RSS or Atom feed (headline, date and link only, never the body), and from founder posts on Plus, which are one line of at most 200 characters, one per day, and one of which can be pinned. A synced entry can be hidden but not deleted, because the next sync would bring it back.
How to connect yours
If you own a verified listing, open its edit page and find the Recent updates panel. Two fields: a GitHub repo and a feed URL. If your listing already links a GitHub organisation, the field is pre-filled with a guess at the main repo. Save, and the entries appear on the listing right away; after that we check every day. Connecting a repo or a feed is free for every claimed listing. Posting your own entries and pinning one is part of Plus. If the listing is not claimed yet, find your tool, claim it, and connect the repo. Our own changelog uses the same format.