Versioning

Where automatic releases happen

Version bumps, git tags, and GitHub Releases are created by GitHub Actions in each repo (workflow release-please on push to main) — not on Vercel and not in the browser. Flow: feature PRs merge to main → Release Please opens a release PR → merge that PR → tag vX.Y.Z + GitHub Release.

REQUIRED_BACKEND_MIN_VERSION is still raised manually in feature PRs when the UI needs a newer API.

How versions link

Do not pin the frontend to a single backend git SHA. Each repo has its own SemVer and git tag (vX.Y.Z). The web app requires:

backend.version ≥ REQUIRED_BACKEND_MIN_VERSION
GET /api/v1/version → { version, apiVersion, gitSha }

When to bump

• New backend endpoint or field the UI uses — bump backend SemVer, raise REQUIRED_BACKEND_MIN_VERSION, bump app version.
• Backend bugfix only — backend patch; frontend min usually unchanged.
• UI-only change — bump app version only.

Release order: backend first → deploy → raise frontend min if needed → release online.

Sources of truth

• Online — package.json version (injected as NEXT_PUBLIC_APP_VERSION), min in src/lib/version.ts
• Backend — pyproject.toml + kulanz_backend/version.py (keep identical)

Backend split docs