On this page
Friday evening is a poor time to discover that "done" has meant several different things all week.
One task is merged. Another is deployed behind a switch. A third works in the test workspace but hasn't had its permission checks reviewed. The release note says all three are available. Nobody wrote a dishonest sentence on purpose. The summary simply arrived before anyone reconciled the states underneath it.
I've come to treat the release note as a useful early test of a release. If I cannot explain what a person will be able to do, I probably haven't settled the scope.
Draft the user-visible change while it is still negotiable
Suppose you are adding filtered exports. Write a rough release sentence before the final implementation push. "Workspace owners can export the filtered task list as CSV. Internal notes stay out of the file."
This is useful precisely because someone can disagree with it. Perhaps members should also export. Perhaps the filter behavior isn't implemented. Perhaps excluding notes is only true on one code path.
You have found a scope or verification question while there is still time to answer it. A release note written after deployment tends to smooth over these gaps because the pressure is to finish the announcement.
The draft doesn't need polished language. It needs a claim concrete enough to test.
A release owner should be able to explain the evidence
I want one person to be accountable for the state of the release, even when several people contribute. That person needs a way to see the included work and its unresolved risks.
A completed task is a useful signal. It is not proof that every sentence in the announcement is true. Permission changes need checks with the relevant roles. An import needs to be exercised with realistic data. A mobile navigation change needs testing on a narrow screen.
The evidence belongs near the work. A test result, a review note, or an explanation of a remaining limitation can be enough. What matters is that someone can inspect the reason for shipping instead of receiving another confident "looks good."
This does not require an elaborate release committee. In a solo project, the same person can make the change and the release decision. Recording evidence still helps, because the person reviewing it tomorrow will have forgotten some of today's assumptions.
Deferred work needs somewhere to go
Late scope changes are easier to handle when the postponed work remains visible. Otherwise every subsequent release begins with someone asking what happened to the missing piece.
For the export, perhaps JSON waits while CSV ships. Record the reason in the release and keep the remaining task linked to its next target. If the remaining work has no credible date, say so. Moving it into a future bucket should not manufacture a promise.
There are limits to splitting. You can't defer access control and call the export complete. You can often defer another output format. The boundary comes from whether the shipped behavior is safe and useful on its own.
I would rather make that call explicitly than ask the team to compensate for unsettled scope with a frantic final day.
History should distinguish intended, delivered, and available
This distinction becomes particularly important when deployment and availability differ. A feature may exist in code before customers can use it. A beta may only reach eligible workspaces. A pricing proposal may be discussed long before anyone is charged differently.
Public updates should say which of those things happened. The version number doesn't do that work for you.
Bisonflow's milestones and optional versions provide a place to group delivery work. The release record is useful when it points back to what supported the change. It is less useful as a second backlog that somebody maintains separately.
AI can help draft a summary from the relevant work, but I still want a person to read every customer-facing claim. A fluent summary can blur "implemented" and "available" as easily as a hurried human can.
The note is finished when a reader can act on it
Before publishing, read the announcement as a customer who has never opened your issue tracker. Can they find the change? Do they know whether they have access? Is there anything they need to do? If a limitation changes how they should use it, did you say so?
Those questions usually improve the writing more than adding another "improvements and fixes" section.
Shipping regularly is valuable. Leaving behind a record that people can trust is what makes the rhythm useful next month, when nobody remembers exactly what happened on Friday.
