Release management is the work of deciding what ships together, when it goes out, and who gets told about it.
Most writing on the subject stops at the first two, which are engineering questions with engineering answers. The third is the one that decides whether anybody notices the work, and it is regularly assigned to whoever is free on the afternoon of the release.
What does release management include?
Four parts, and they belong to different people.
Scope. What is in this release and what waits for the next one. This is a product decision dressed as a scheduling one.
Timing. Fixed dates or continuous deployment, and every arrangement between them. The trade is predictability against the cost of holding finished work.
Verification. What has to be true before it goes out, from tests to a staged rollout to somebody clicking through it.
Communication. The changelog entry, the notification, the documentation update and the answer support gives when somebody asks what changed.
Why does the communication part get skipped?
Because it is the only part with no failure alarm.
A broken deploy pages somebody at two in the morning. A missing changelog entry produces nothing at all, except a slow accumulation of customers who believe the product never changes.
The damage is real and it arrives quarters later as a renewal conversation where somebody says they were not sure the product was still being developed.
The second reason is that the writing feels like a chore for a feature that is already done.
The fix is to make it the last step of the release rather than a separate task, which is why keeping the notes where the release is assembled works better than keeping them in a document somebody has to remember.
How does a public roadmap change release management?
It converts the schedule into a promise, which is useful and dangerous in equal measure.
The useful half is that a board with a planned column does most of the work of a release announcement in advance. People who care about a request have already said so, and telling them when it lands is a matter of who voted rather than a broadcast to everybody.
The dangerous half is that dates on a public roadmap are read as commitments however many disclaimers sit above them.
The convention that survives contact with customers is columns rather than dates, so the roadmap says what is being worked on and the changelog says what actually landed. How the roadmap columns work here is written out in full.
What is the difference between a release and a changelog entry?
A release is a thing you did. A changelog entry is a thing you said, and the second one is for a different audience than the first.
Engineering releases are versioned, granular and often several a day. A changelog for customers is edited, grouped and infrequent, because a customer reading twelve entries about internal refactoring learns nothing.
The mapping between them is editorial rather than automatic, and any tool that promises to generate customer notes from commits is promising to skip the editing step. What separates a changelog from release notes is written up separately.
Who should be told when something ships?
The people who asked for it, first and specifically.
That is the part a feedback board makes cheap. Every request carries the voters behind it, so shipping a request is also a list of people with a reason to care.
A message that says the thing you asked for in March is live is read at a rate no general announcement ever matches, and it is the moment that teaches people that filing a request is worth doing.
Everybody else gets the ordinary changelog, on a page or in the product, and that is enough. How the changelog is written and published here is on its own page.
14 days, a card at signup, then $9 or $39 a month.