RELEASING.md

Releasing

Ownima uses Release Please to automate versioning and changelog generation.

How it works

Release Please watches commits on main and derives the next version from conventional commit prefixes:

Commit prefix	Version bump	Example
fix: ...	patch	0.2.28 → 0.2.29
feat: ...	minor	0.2.28 → 0.3.0
feat!: ... or BREAKING CHANGE: in the body	major	0.2.28 → 1.0.0
chore:, docs:, refactor:, ci:, …	none	no release PR on its own

On every push to main it either:

1. creates or updates a release PR titled chore(main): release X.Y.Z with an autogenerated changelog, or
2. tags and releases when that PR is merged.

Repositories

Repository	Versioning
owner-api	release-please-config.json + .release-please-manifest.json (key ownima-backend)
owner-web	release-please-config.json + .release-please-manifest.json
booking-web	release-please-config.json + .release-please-manifest.json
rider-app	release-please-config.json + .release-please-manifest.json

They use a GitHub App token (OWNIMA_BOT_APP_ID + OWNIMA_BOT_PRIVATE_KEY) instead of GITHUB_TOKEN, because the organization restricts PR creation for Actions. rider-app builds and deploys on Vercel from main.

Workflow

push to main
    └─► release-please runs
            ├─ no releasable commits → nothing happens
            └─ releasable commits found
                    ├─ release PR already open → updates it
                    └─ no open release PR → creates one
                                └─ merge release PR
                                        └─ creates git tag + GitHub Release

Tips

• Force a version: put Release-As: X.Y.Z as a trailer in a commit on main. Release Please picks it up on the next run.
• Hold a release: leave the release PR open; it keeps updating.
• Non-releasable commits (chore:, ci:, docs:) do not trigger a release PR on their own, but they do not reset one that is already open.