Skip to content

Releases

Releases and Versioning

Understand how Origin turns merged work into tagged releases, package versions, binaries, npm packages, and crates.

Qi-Xuan LuUpdated 5 min read

At a glance

01

CHANGELOG.md and GitHub Releases are the user-facing record for shipped behavior.

02

release-please prepares the release PR; tag workflows publish the local runtime packages and binaries.

01

Release source of truth

For users, the shipped record is the GitHub release, CHANGELOG.md, and the packages installed by the Claude Code plugin or npx setup.

Merged PRs can describe useful work, but they are not the same as a release until a tag and changelog entry publish that behavior.

Read the changelog

02

How a release moves

Origin uses release-please to maintain a release PR from merged commits. When that release PR is merged, tag-based workflows build and publish the local runtime.

The release workflow ships the daemon CLI, origin-server, origin-mcp, standalone binaries, npm packages, crates, and Homebrew tap updates. The optional desktop app releases from its own repository.

Release flow

merge to main
  -> release-please updates the release PR
  -> merge the release PR when ready to ship
  -> tag workflow builds binaries and publishes packages
  -> users refresh with npx -y @7xuanlu/origin setup

03

Version bump rules

Origin is pre-1.0, so release bump semantics are intentionally conservative. In this repo, feat commits bump the minor version before 1.0; fix commits bump patch.

Squash merge titles matter because the squash commit message is what release-please reads. A PR titled feat: should only land that way when a minor release is intended.

Commit prefixes

fix:              patch release before 1.0
feat:             minor release before 1.0
BREAKING CHANGE:  minor release before 1.0
docs/test/chore:  no release entry by default

04

What gets published

The release pipeline publishes the pieces users install: @7xuanlu/origin for the Claude Code plugin and setup path, origin-mcp for MCP clients, origin-types for Rust consumers, release archives, and Homebrew artifacts.

Version files in the repo stay aligned so the CLI, daemon, MCP connector, npm packages, and crates all describe the same runtime generation.

Read package names

05

How users should upgrade

Users should read the changelog, rerun npx setup or /init, verify origin doctor, and restart MCP clients after package or connector changes.

If a page says a feature is on main, opt-in, or experimental, do not assume it is available in your installed runtime until a release page says so.

Read upgrade notes

Next

Roadmap and Status

How to read Origin's current direction without confusing released features, main-branch work, and future bets.

Read next