Versioning

On the web you can redeploy without anyone noticing. That is the point of continuous delivery, and it is also why teams skip versioning until a support ticket asks "which build am I on?"

A product version is the shared label for everything that shipped together: the UI, the API contract your clients assume, the migration that ran, the flag defaults that flipped. Without it, analytics, error reports, changelogs, and rollbacks all become archaeology.

Why bother at all?

Stores do not force a number on you. You still want one because:

• Support - screenshots and tickets that say v1.8.2 beat "I think I refreshed yesterday".
• Observability - group crashes and sessions by release instead of by deploy time guesswork.
• Communication - changelogs, status updates, and "we rolled back to …" need a name.
• Coordination - marketing, mobile, and API consumers can talk about the same cut of the product.

Git SHAs are great for engineers. Users and most support tools are not. Keep a human version (1.8.2) even if your host also stamps every deploy with a commit.

Bumping versions

Semantic Versioning is enough for most SaaS apps:

Bump when the release is worth talking about, not on every typo commit. Pair the bump with the production deploy so the live site and the label never drift.

Pre-release tags (1.9.0-beta.1) help for staging if you need them. Production versions stay clean so dashboards and tickets stay readable.

Best practices

• One product version for the app users meet. Do not confuse it with dozens of workspace package versions in a monorepo.
• The same value everywhere you show or send "app version" (UI, support macros, error context).
• A short human note per release (changelog or release description). The number alone does not explain what changed.
• Independence from mobile and extension listings. Those follow store review cycles; your Next.js deploy does not have to match their numbers.

In TurboStarter

The kit already exposes a single product version from apps/web/package.json through appConfig.version (shown in the marketing footer). Bump that field with the deploy you care about tracking:

{
  "version": "1.8.1", 
  "version": "1.8.2"
}

Deploy flow: deployment checklist. Optional next step: pass appConfig.version into your monitoring provider so production issues group by release.