Release management is one of those things that looks invisible when it's done right and excruciating when it's not. For years Linear users worked around the absence of a real release primitive — version labels, groups, custom statuses, hand-rolled scripts. It all worked. It also broke quietly: a label rename forgotten across teams, an issue stuck in "Awaiting Release" three sprints in a row, a stakeholder asking "so what's actually in production?" and nobody being sure.
Then Linear shipped Linear Release — a first-class entity with pipelines, stages, versions, and a CI integration. This post is a review of the feature with notes from migrating a real marketplace project off the old label setup.
How we did it before
Without a release object, every team invents its own protocol. Mine went like this. Every issue heading into a deploy got a version label — next_v1.5.0_marketplace — which lived inside a Linear label group called Versions. The group exclusivity flag made sure no issue could carry two version labels at once. After the deploy, we renamed next_* to current_*, and the previous current_* got renamed to old_*. A separate "Release vX.Y.Z" issue tracked the QA checklist for the deployed build.
The custom CI part filled the gaps: a dispatch-triggered GitHub Actions workflow analyzed commits, decided whether the next bump was major/minor/patch, generated CHANGELOG entries, opened a release PR into main. A custom skill then walked the labels, created the milestone, drafted the QA issue, and published a project update — pre-deploy. After merge, the same skill renamed labels, moved issues to In Prod, updated the releases doc, posted the post-deploy update.
It worked. The downside was obvious: every part of it was a workaround. The system carried meaning the platform didn't see. New teammates needed a written runbook to understand what next_ vs current_ vs old_ meant. And the only place the deploy itself was reflected in Linear was a manual status update someone had to remember to write.
What Linear Release actually is
Linear Release introduces three primitives that the old label setup approximated by hand:
- A pipeline is one independent stream of releases. A web app shipping on merge is one pipeline; an iOS app on a 2-week train is another; a nightly dogfood build is a third. Each has its own version history and its own access key.
- A stage is a phase inside a single release on a pipeline — code freeze, in QA, RC soak. Stages are gates on the same build, not separate streams.
- A version is what a deploy actually produces — created by CI, not by a human typing into a label field.
Pipelines come in two flavors: continuous (every deploy completes a release — typical for web apps shipping on merge) and scheduled (releases collect changes, move through stages, then ship — typical for versioned mobile and on-prem). The split matters because the wrong choice makes the model feel awkward; the right choice makes it disappear.
The actual integration is a small action in your workflow:
- uses: linear/linear-release-action@v0
with:
access-key: ${{ secrets.LINEAR_ACCESS_KEY }}
command: sync
That's the whole shape of it. The action reads commits, maps them to Linear issues, and updates the active release in the pipeline. No webhook gymnastics, no MCP scripts, no label renaming.
A quick word about Jira
Jira has had fixVersion for two decades. The fact that Linear is only now catching up is fair criticism — release tracking is a release-management 101 feature. But the way Linear got there is different in a way that matters.
Jira's release object is a catalog entry — you create it ahead of time, attach issues, ship it. The system doesn't really know your CI. The Jira-CI link is whatever plugin you bolt on (Bitbucket, Jenkins, GitLab — pick your integration tax).
Linear's release is a CI artifact — the action runs on every deploy, the version is whatever your branch or tag says, and the issue association is computed from commits. The catalog is downstream of the deploy, not upstream of it. For teams that actually ship multiple times a week, this inversion is what makes the difference.
The downside is honesty: if your release process is irregular and human-driven, Jira's catalog model still feels more natural. Linear Release wants you to deploy from CI.
How I'm wiring it up
In my marketplace project the setup looks like this. A dispatch-triggered release-prepare workflow still does the version bump + changelog + release-PR part — that's pre-deploy mechanics, orthogonal to Linear. What changed is what happens after merge to main.
The Vercel auto-deploy still runs. The auto-tag and GitHub Release still happen. But now a second job in the same workflow also calls the Linear Release Action. The pipeline is continuous (we ship on merge), the version comes from package.json, the action does the rest — finds commits since the last release, resolves their issue keys, and closes out the release on the matching pipeline.
What stays — and matters — is the business update layer. Linear gives you releases; it doesn't give you a stakeholder-friendly summary of what shipped. That's still my responsibility to generate, but now from a structured release object rather than from labels.
Manual label ops per release
Cross-team sync steps
CI lines added
Custom skill size
What this gives you
The boring answer is visibility. The interesting answer is visibility for people who don't read Linear daily.
Non-technical stakeholders ask three questions: what shipped, when, and what's coming. Before Linear Release, those answers lived in three different places — labels, status updates, a project doc. Now they live on the release itself: the version, the deploy timestamp, the issues, the stage. Each release has a stable URL you can paste anywhere.
For engineering, the bigger win is connecting deploys to issues automatically. If you've ever had to manually move 14 issues from "Awaiting Release" to "In Prod" because someone deployed during your lunch break, you know the cost of the old way. CI does that now.
What's still missing
Two gaps stand out.
The first is Slack delivery. Linear has Slack integration generally, but release notifications still need a Zap/workflow to post a nice "v1.5.0 just shipped — here's what's in it" message into a channel. For a feature whose whole point is non-technical visibility, that's a strange omission.
The second is business-update generation. A release object knows the issue list, but turning that into a stakeholder summary — grouping subtasks under parent features, hiding internal tech-debt items, flagging feature-flagged work — is still custom logic. I keep that in a skill. It would be nice if Linear had a template hook here.
A third minor gripe: changelog generation. The action knows commits, the GitHub Release has a changelog, but Linear's release detail doesn't surface the changelog text directly. You can link out, but it's an extra click.
Closing
The label-and-group era of Linear releases was a long workaround for a missing primitive. The custom CI and skills I built around it weren't wasted — they encoded knowledge that the platform now expresses natively. But it's the difference between explaining a runbook to every new engineer and pointing at a URL.
Linear Release isn't the most ambitious feature Linear has shipped, but it's the one I notice the least — which, for release management, is the highest compliment you can pay it.