Semantic Versioning (SEMVER)

SEMVER (semver.org) uses MAJOR.MINOR.PATCH (e.g. 2.4.1). Users and support teams rely on version numbers to understand change risk. Mobile adds a separate monotonic build number required by stores.

MAJOR.MINOR.PATCH explained

SEMVER (semver.org) uses MAJOR.MINOR.PATCH (e.g. 2.4.1). Users and support teams rely on version numbers to understand change risk. Mobile adds a separate monotonic build number required by stores.

Pre-release versions: 2.5.0-beta.1, 2.5.0-rc.2 — useful for TestFlight and Play Open Testing tracks.

SEMVER decision flowchart

When to bump each segment

MAJOR (3.0.0): breaking API changes, removed features, minimum OS version bump, major redesign.
MINOR (2.5.0): new screens, features, non-breaking native module updates, new permissions.
PATCH (2.4.1): crash fixes, copy changes, hotfixes, performance tweaks without new features.
Build number: increment on EVERY store upload, even if marketing version unchanged (iOS resubmit).

Conventional commits → version bump

feat: add biometric login       → MINOR (2.4.0 → 2.5.0)
fix: crash on logout             → PATCH (2.4.0 → 2.4.1)
feat!: remove legacy auth API    → MAJOR (2.4.0 → 3.0.0)
docs: update README              → no version bump
chore: bump eslint               → no version bump (usually)