The release note clarity gap

How often does a release note fail to say what changed, and does it depend on where the vendor publishes it?

3.7%

of all 33,974 release notes offer no detail about what changed, or one in twenty-seven.

29.1%

on play, or one in three. No channel in the catalog has more room to improve.

3.7%

on GitHub, or one in twenty-seven, from the same measurement on the same day.

Of the 33,974 releases in this catalog whose notes contain any prose at all, 1,252 describe that something changed without describing what. That figure averages over channels that behave nothing alike, so it is best read as a starting point. The more useful signal is where clear release communication is already working—and where a modest change could help most.

Where a vendor publishes predicts how clearly they communicate

On play, one in three notes gives no detail: 29.1% of 151. On GitHub it is one in twenty-seven, or 3.7% of 19,240. Both came from the same measurement on the same day, and they sit about 8× apart.

The likeliest explanation is the publishing environment, not the effort behind the release. An app store listing is a compact marketing surface, with a character limit and a review queue between the writer and the reader. A release on a forge is usually written closer to the work itself, for people looking for implementation detail. That makes channel choice a practical lever for clearer communication.

By the kind of source the notes came from, as a share of that channel's own releases. Bars are to scale, with the full width standing for every note. Channels with fewer than 50 releases are not ranked.
play29.1%44/151
appstore24.0%236/982
jetbrains11.4%36/316
scrape6.6%89/1,343
github3.7%720/19,240
feed3.7%117/3,197
sparkle1.3%3/233
gitlab0.6%1/155
steam0.1%5/7,115
versions0.0%0/213
registry0.0%0/412
riot0.0%0/394

The clearest opportunity is what happens after the link

37% of the low-information notes in this catalog announce a real, published release and then send the reader elsewhere to learn what changed. The information often exists; bringing one useful detail forward would make the note substantially more helpful.

How the 1,252 low-information notes divide. Every one falls into exactly one shape, so these four make a whole.
A link to the changelog36.9%462/1,252
Bug fixes and improvements32.3%404/1,252
The version, again27.0%338/1,252
A maintenance release3.4%42/1,252
Nothing at all0.5%6/1,252
A link to the changelog
The note exists and refers the reader somewhere else.
Bug fixes and improvements
An update happened. The note does not say what it was.
The version, again
A name and a number, which the page already showed.
A maintenance release
The same claim in the words a developer channel uses.
Nothing at all
Whitespace, or punctuation with no words in it.

One of each, from the catalog

By what the software is

This is mostly the table above, re-sorted: categories differ because the products in them publish in different places. It shows where teams can learn from categories that consistently give readers more useful release detail.

By product category.
CategoryNo detailReleases read
Lifestyle & Apps33.1%472
Drivers14.2%134
Communication8.1%1,316
AI6.9%4,147
Infrastructure & DevOps6.9%2,647
Operating Systems6.6%669
Languages & Runtimes6.4%326
Databases & Data5.7%1,121
Creative Tools4.6%667
Security & Privacy4.3%1,247

How this is measured, and where it is weak

  • A pattern detector, not a judgement about quality. A note counts as low-information when it matches one of four shapes: a pointer at the real notes, storefront boilerplate, a restatement of the version, or a generic “maintenance release”. A short note that names a real change, like “Switch to libusb 1.0.27”, does not count, and neither does a dependency bump. The test is whether the note says what changed, not whether the change was worth much.
  • Some of these pointers are ours, not the vendor’s. When a release links to a changelog file, What’s New can often follow the link and store what it finds, and where that is set up the note shown here is the real one. Where it is not, the release still reads as a pointer. 436 of the pointers counted above sit on sources that name no changelog for us to follow. Those vendors did publish notes. We have not fetched them.
  • It counts four shapes, so every figure is a floor. A note that withholds detail in some way none of these four shapes describe is counted as substantive. The real number is higher than the one on this page, and it will be furthest off in the channels least like the ones these shapes were drawn from.
  • Steam is a promising result that still needs validation. It is the largest channel here and its rate is near zero. That may reflect a real strength: game patch notes are written for players who actively use them. It may also reflect a fifth pattern the detector does not yet recognize, so the result should be treated as encouraging rather than conclusive.
  • Long notes go unexamined. 22,267 of the 33,974 notes were short enough to examine; anything over 2,000 characters is counted as substantive without being read. The longest note that has ever matched is 460 characters, so this is unlikely to hide much, but it is an assumption rather than a proof.
  • The catalog is not the world. These are the products What’s New tracks, which skews toward software that publishes a changelog at all. A vendor who publishes nothing cannot appear here, so everyone measured is already making some effort.

Recomputed every week. Every figure comes from the catalog at build time rather than being typed in.

Better release notes rarely require more writing. One concrete detail, placed where readers already look, can be enough. Declarative Changelogs is a practical proposal for publishing notes that a machine can read and a person can skim. This research shows where that approach can have the most impact. You can also browse any product’s full history and judge for yourself.