Documentation Index

Fetch the complete documentation index at: https://docs.document360.com/llms.txt

Use this file to discover all available pages before exploring further.

Disclaimer: Dit artikel is gegenereerd door automatische vertaling.

Release notes

  • Gepubliceerd op Jul 27, 2026
  • 5 Gelezen minuut(en)
Prev Next
This content is currently unavailable in Dutch. You are viewing the default (English) version.

What Is a Release Note?

A release note documents what changed in a product update. It tells readers what is new, what was fixed, what was improved, and what was deprecated or removed. Release notes serve a broad audience: customers who need to understand the impact of an update, internal teams preparing to support new features, and partners integrating with your product. See the Content That Doesn't Fit Neatly section of the Five Core Content Types guide, which flags release notes as a recognized exception that borrows from reference (structured, scannable) and how-to/conceptual (explains impact and links to detail) without fully matching any single type; this article is the fuller treatment of that entry.

Good release notes are specific, complete, and honest. Vague entries ("Various performance improvements") erode trust. Specific entries ("Reduced article publish latency by 40% for projects with more than 10,000 articles") build it.

Customer-facing vs. internal release notes: this guide covers customer-facing release notes. An internal release note — written for Support, Success, and GTM teams ahead of a release — is a related but distinct artifact with a different audience and often different content (e.g., internal rollout timing, support talking points), not simply a shorter or more technical version of this one. See the Public vs. Private Knowledge Base Structure section of the Knowing Your Audience guide for the general principle behind this distinction.

Structure of a Release Note Page

Each release note is typically a single article covering one release. Use the following structure.

Title

Use the format: [Month] [Year] — [Version number]

Example: May 2026 — 12.5.1

Release date

State the date the release was deployed: "Released: 29 May 2026," using the unambiguous prose date format specified in the Numbers, Dates, and Time guide. If your release notes are localized, see the Dates guidance in the Dates, Numbers, and Units for Localization guide — a release date is exactly the kind of specific, translatable date that needs to reformat correctly per locale, not carry the English format through.

Sections by change type

Group release note entries under consistent section headings. Use these standard headings:

  • New features — functionality that did not previously exist.
  • Improvements — enhancements to existing features.
  • Bug fixes — resolved defects. List specific symptoms that were fixed.
  • Deprecations — features being phased out with a timeline.
  • Breaking changes — changes that may require action from customers. Always highlight these prominently.

Omit sections that do not have entries for that release. Do not include empty headings.

Writing Individual Release Note Entries

Each entry should follow this pattern:

  • What changed — one sentence stating the change clearly.
  • Why it matters — one sentence explaining the benefit or impact to the reader.
  • Link to documentation — a link to the how-to or conceptual article covering the feature.

Example entry (new feature)

Eddy AI feedback categorization
Eddy AI now automatically categorizes feedback by topic, making it easier to identify patterns across large volumes of article feedback. [Learn more]

Example entry (bug fix)

Fixed: Articles exported as ZIP files were missing images
Articles that contained images uploaded via Drive were missing those images in ZIP export. This has been resolved.

Example entry (breaking change)

Warning: Breaking change — API token format update
API tokens generated before 1 June 2026 will stop working on 1 September 2026. You must regenerate your tokens before this date. [How to regenerate API tokens]

Use the standard Warning callout format from the Callouts guide for breaking changes, with the text label "Warning" always present alongside any icon — an icon or symbol alone does not meet the accessibility requirement that callout type never be conveyed by icon or color alone.

Template

[Month Year — Version]

Released: [DD Month YYYY]

## New features

**[Feature name]**
[One sentence: what changed]. [One sentence: why it matters]. [Link to docs]

## Improvements

**[Feature name]**
[One sentence: what improved]. [One sentence: impact]. [Link to docs]

## Bug fixes

**Fixed: [Symptom description]**
[One sentence: what the bug was and that it is resolved].

## Breaking changes

> **Warning: [Change name]**
> [One sentence: what is changing]. [One sentence: what action is required and by when]. [Link to docs]

## Deprecations

**[Feature name] deprecated**
[One sentence: what is being deprecated]. [One sentence: timeline and what to use instead]. [Link to migration guide]

Writing Guidelines for Release Notes

  • Be specific. Avoid vague entries. "Improved performance" is not a release note. "Reduced page load time for knowledge bases with more than 5,000 articles by up to 35%" is.
  • Write from the customer's perspective. Focus on impact and benefit, not on internal implementation details.
  • Use consistent terminology. Refer to features by their exact names in the UI.
  • Link to the documentation. Every entry for a new feature or significant improvement should link to the relevant article. Do not make readers search for how to use what you just announced.
  • Flag breaking changes prominently. Use the standard Warning callout and list breaking changes in their own section. Never bury a breaking change under "Improvements."
  • Tense: use past tense to describe that a change occurred ("Fixed: X was not saving correctly," "Added support for CSV imports"). Present tense is also acceptable specifically when describing the resulting capability itself, framed with "now" ("You can now export directly to PDF from the editor") — this is describing the current state of the product, not narrating the release event, which is why it's an acceptable variation rather than an inconsistency with the general past-tense rule for release notes in the Verbs, Tense, and Mood guide.

Tone

Clear and informative. Release notes have a slightly more direct, factual tone than other documentation. They are announcements as much as documentation. Be concise. A release note entry is not a marketing paragraph — save promotional language for announcements and blog posts. This is a tighter, more neutral register than the intentionally warmer tone permitted in the Writing Effective Notification and Transactional Emails guide; release notes and announcement emails serve related but different purposes, and shouldn't be written in the same voice.

Self-Audit Checklist

Before publishing, check the release note against these questions:

  • Does the title follow the [Month] [Year] — [Version] format?
  • Is the release date in the unambiguous prose format, localized correctly if applicable?
  • Are only the sections with actual entries included, with no empty headings?
  • Does every entry state what changed, why it matters, and link to documentation where relevant?
  • Are all breaking changes flagged with a proper Warning callout, with a text label rather than an icon alone?
  • Is every entry specific, with a concrete number or scope rather than a vague claim like "improved performance"?
  • Does terminology match the exact feature names used in the UI?
  • Is tense used consistently — past tense for the change itself, present tense only for describing the resulting capability?
  • Is the tone factual and concise, free of promotional language?
  • If this release involves an internal audience (Support, Success, GTM), has a separate internal release note been considered rather than assuming this one covers both?