How to Set Up a Release Notes Workflow in Linear
Release notes that go out every sprint create user trust. Release notes that are written manually from memory at 11pm every other week create errors and omissions. A release notes workflow in Linear uses the data already in your issue tracker — issue titles, descriptions, and completion dates — to generate consistent, accurate release notes with minimal manual work.
This guide covers how to build a release notes workflow from Linear cycle data: the label structure that separates customer-facing changes from internal work, the template that structures the release note, and the review process before it goes to customers.
Step-by-step guide
Set up release note labels in Linear
Create a Linear label group called "Release Notes" with three labels: "Release Note: Feature" (new functionality customers can use), "Release Note: Improvement" (changes to existing functionality), and "Release Note: Fix" (bugs that customers reported or noticed). Create a fourth label "Internal Only" for changes that are real engineering work but should not appear in customer release notes (refactors, dependency updates, infrastructure changes). Apply these labels during sprint planning or issue creation — not retroactively at release time.
Write issue titles in release-note format
Train the team to write Linear issue titles in a format that can be published as release notes: "Add export to CSV on the Projects dashboard" instead of "ENG-456 implement CSV export backend + frontend." The title should describe the user-visible change in plain language. Add a "Customer Impact" description field to each Release Note labeled issue: one sentence on what the user can now do, written in second person: "You can now export your project list as a CSV file."
Generate the release note draft from a completed cycle
When a cycle completes, open the cycle view and filter to issues with any "Release Note:" label. Export the filtered issue list. The release note draft structure: [Release number / date], "What's New" section (issues labeled Release Note: Feature), "Improvements" section (Release Note: Improvement issues), "Bug Fixes" section (Release Note: Fix issues). The issue titles and Customer Impact fields become the release note line items. This draft is 80% complete before any manual writing.
Create the release note review workflow
Create a Linear project called "Release Notes" where each release is a project. Add the draft release note as a Notion page (or Confluence page) linked from the Linear project. The review checklist: PM reviews for accuracy and tone, Marketing reviews for messaging alignment, Support reviews for anything that changes workflows customers rely on. Each reviewer approves in the Notion comments or checks off a Notion checklist. Only after all approvals does the release note go to customers via email, in-app banner, or changelog page.
Publish and distribute the approved release note
Define your release note distribution channels based on impact: Minor releases (bug fixes + small improvements) — in-app changelog only. Major releases (significant new features) — in-app changelog + email to active users + announcement in customer Slack channels. The Linear "Release Note: Feature" count per cycle determines which tier applies. After publishing, create a brief Slack post in your customer-facing channel with a 3-bullet summary linking to the full release note.
Common mistakes
Writing release notes retroactively from memory
Engineering teams that write release notes after the sprint closes spend 2-3 hours reconstructing what shipped. This produces incomplete notes that miss fixes and misrepresent features. The "Release Note:" label and Customer Impact field must be filled in during issue creation — before the sprint starts. The release note draft then takes 20 minutes, not 3 hours.
Technical language in customer-facing release notes
"Refactored authentication middleware to reduce token validation latency by 40ms" is engineering news, not customer news. Translate every release note item into customer value: "Sign-in is now 2× faster." The test: would your non-technical customers understand this sentence and care about it? If not, rewrite it or move it to an internal engineering update.
No distinction between customer-facing and internal changes
Without the "Internal Only" label, the release note draft includes every issue in the cycle. Engineers then spend the review period deciding what to cut. The Internal Only label makes the decision at issue creation time when context is fresh. The release note draft then contains only customer-relevant changes from the start.
Tips
Create a Linear automation: when a cycle ends, automatically create a "Release Note Draft" issue in the Release Notes project with a link to the completed cycle — this creates the trigger for the release note workflow without requiring a manual kickoff
Use Linear's changelog feature (available in some plans) to publish release notes directly from completed cycles with a custom domain — this creates a permanent release history without a separate changelog tool
Track open rate on your release note emails using your email provider's analytics — consistently low open rates signal that the frequency, length, or value of the release notes needs adjustment. Release notes no one reads are noise, not communication
How Vantage helps
Release notes communicate what shipped to customers. Vantage connects release notes to the product requirements that drove each feature: when a customer asks "why did you build X?" the release note traces back to the PRD requirement, which traces back to the signal that surfaced the problem. This traceability is useful for customer success and sales conversations about product direction.