Version Bump Rules

Version Control — Mandatory Practice

Every software project must maintain a version number. Every change that reaches production or main branch must bump the version in the same commit — no exceptions, no deferral.

Where version lives (by project type)

Critical: WXT extension gotcha

Browser extensions built with WXT read the version from wxt.config.ts in the manifest block, not from package.json. Bumping only package.json leaves the manifest at the old version, so users see stale version info in the browser extension UI.

Always verify wxt.config.ts when working with WXT projects.

Semantic versioning rules

MAJOR.MINOR.PATCH
  │      │     └── bug fix, cosmetic adjustment, refactor with no external impact
  │      └──────── new feature, backwards-compatible (new behavior, new UI, new integration)
  └─────────────── breaking change (removed behavior, changed public interface, mandatory migration)

When in doubt between MINOR and PATCH? If the end user will notice → MINOR. If only internal code changed → PATCH.

Anti-patterns (mandatory to avoid)

• Committing a new feature without bumping the version → forbidden
• "I'll bump it later" → deferral is not allowed. Bump in the same commit or merge commit
• Version frozen at 0.0.1 while product evolves → traceability failure
• Multiple packages in a monorepo with different versions without justification → align them if they release together