Releases

Releases are automated with release-please. You never bump a version or write a changelog by hand - Conventional Commits do it.

How it works

flowchart LR
  C[Conventional commits on main] --> RP[release-please]
  RP --> PR[Release PR: changelog + version bump]
  PR -->|you merge| GH[Git tag + GitHub Release]

1. As feat: / fix: commits land on main, release-please opens (and keeps updating) a release PR titled chore(main): release X.Y.Z.
2. That PR bumps the version in package.json, app.json (expo.version), and .release-please-manifest.json, and regenerates CHANGELOG.md.
3. When you merge the release PR, release-please creates the Git tag and the GitHub Release with the changelog notes.

Version bumping

While the project is pre-1.0, the config bumps conservatively:

{
  "bump-minor-pre-major": true,
  "bump-patch-for-minor-pre-major": true
}

• fix: -> patch
• feat: -> patch (pre-1.0; would be minor after 1.0)
• feat!: or BREAKING CHANGE: -> minor (pre-1.0)

Config lives in release-please-config.json and the current version in .release-please-manifest.json.

Cutting a release

There is nothing manual to do beyond merging:

1. Land your feature PRs on main with conventional commit messages.
2. release-please updates the open release PR automatically.
3. Review it, then merge it. The tag and GitHub Release appear within a minute.

Tagging app builds to a release

After a release is tagged, build the matching binary from that tag:

git checkout vX.Y.Z
eas build --platform all --profile production

See App builds for the EAS details.