Bi-directional Linear Sync

Launch edition: this release note describes a feature in UpdateTinus's early-access preview; details may change before general availability.

A note on third parties: this integration is in beta and depends on services operated by other companies, whose APIs, limits and terms can change. UpdateTinus is not affiliated with, endorsed by or partnered with those companies, and all product names and trademarks belong to their respective owners.

Most teams already track their work carefully in an issue tracker. Every bug fix, small polish and big feature lives there, with a title, a description and a status. The trouble is that none of that context flows naturally into the changelog. Someone has to go back through a week of closed issues, decide which ones users care about, and rewrite them in friendly language. In v2.4.0 of the UpdateTinus preview we have improved our Linear sync so that work flows in both directions.

From closed issue to changelog draft

Once you connect a Linear workspace, you choose which teams and labels UpdateTinus should watch. When an issue matching those rules moves to a completed state, UpdateTinus creates a changelog draft. The draft is pre-filled with the issue title, a cleaned-up version of its description, and any labels that map to UpdateTinus tags.

The draft is a starting point, not a finished announcement. Issue titles are written for engineers ("Fix race in token refresh"), while release notes are written for people ("Staying signed in is now more reliable"). The canvas highlights the original issue text beside the draft so you can translate it comfortably.

Grouping related issues

Many user-facing changes are made of several issues. A new export feature might involve a backend issue, a design issue and two bug fixes. You can now merge multiple drafts into one release note, and UpdateTinus keeps a record of every issue that contributed. Drafts can also be grouped automatically by Linear project or cycle if your team works that way.

From published note back to the issue

The "bi-directional" part is what makes this an improvement rather than a one-way import. When a release note is published, UpdateTinus can add a comment or attachment to each linked Linear issue with the public link to the announcement. That small loop helps in several ways:

• Engineers can see how their work was described to users.
• Support can find the announcement straight from the issue a customer reported.
• Product managers can tell at a glance which completed work has been communicated and which has not.

If an issue is later reopened, UpdateTinus flags the related release note in your workspace so you can decide whether it needs a correction or a follow-up.

What we improved in this version

Earlier preview builds offered a basic import. This release focuses on making the sync calmer and more predictable:

1. Fewer noisy drafts. Label and team filters are now stricter, and issues closed as duplicates or "won't do" are skipped by default.
2. Better formatting. Markdown from issue descriptions is converted more faithfully, and internal checklists are removed from drafts.
3. Clear sync status. Each draft shows whether its links back to Linear succeeded, are pending, or need attention.
4. Safer defaults. Nothing is published automatically; the sync only ever creates drafts unless you change that explicitly.

Mapping labels to tags

UpdateTinus uses friendly tags such as New Feature, Improvements and Beta to help readers scan a changelog. In the sync settings you can map your Linear labels to these tags. For example, a feature label might map to New Feature, while bug and polish both map to Improvements. Unmapped labels are ignored, so internal labels never leak into public notes.

Keeping private work private

Not every completed issue should appear on a public changelog. Security fixes, internal tooling and experiments often belong elsewhere. You can exclude specific teams or labels entirely, and drafts created from issues marked as sensitive are routed to a private roadmap view rather than the public changelog queue. Comments posted back to Linear contain only the public announcement link, never private draft content.

The sync should save you time, but it should never make a decision about what your users see. That decision stays with your team.

An illustrative week

Here is an illustrative example, not data from real users. Imagine a small team closes twelve issues in a week. With the sync filtered to user-facing labels, perhaps five of them become drafts. The team merges three related drafts into one feature announcement, polishes the remaining two as small improvements, and publishes on Friday. Each of the original issues now links to the note that describes it, and nobody had to dig through the tracker by hand.

Limitations

This sync is in beta and depends on Linear's API, permissions and rate limits. If Linear changes how its API behaves, some parts of the sync may pause until we update. Large backfills of older issues are not supported yet; the sync starts from the moment you connect. And because the integration acts on your behalf, it only sees teams and issues that the connected account can access.

Getting started

Early-access workspaces can enable the sync from the integrations page. Start with a single team and one or two labels, watch the drafts arrive for a week, and adjust your filters from there. We would love to hear how it fits into your process, especially if your team uses cycles, projects or triage in ways we have not anticipated. Share your notes on the feedback board and we will keep improving.