Semantic versioning
Numbering releases as major.minor.patch so the version signals whether an upgrade is intended to be breaking.
See it
What it is
Semantic versioning turns a version number into a promise. In MAJOR.MINOR.PATCH, you bump major when you break something existing users depend on, minor when you add features in a backward-compatible way, and patch when you only fix bugs. So 2.4.1 to 2.5.0 should be a safe upgrade, and 2.5.0 to 3.0.0 means read the changelog first.
That promise is what dependency ranges are built on. A caret (^1.4.2) accepts minor and patch updates but not the next major; a tilde (~1.4.2) accepts patches only. Suffixes cover the rest: 1.0.0-beta.2 is a prerelease that sorts before 1.0.0, and 0.x is the explicit 'anything can change' zone, which is why 0.3.0 to 0.4.0 is allowed to break you. Conventional commits plus a release tool can compute the bump and the changelog from your commit messages.
The honest gotcha: semver is a social contract, not a guarantee. Whether a change is breaking depends on what people actually rely on, including behavior you never documented, and plenty of teams ship breaking changes in a minor by accident. Marketing also mugs it, hence products that jump to version 5 for the launch. Trust it enough to automate, not enough to skip the changelog.
Ask AI for it
Set up semantic versioning and automated releases for this repo. Enforce conventional commits (feat, fix, chore, plus BREAKING CHANGE footers) with a commit lint hook, then add a release workflow that derives the next major/minor/patch version from the commits since the last tag, generates a grouped CHANGELOG.md, and creates the git tag and GitHub release. Then work out what this repo actually ships: an npm package, a container image, a compiled binary, or nothing publishable at all. Publish to the registry already configured for that artifact and name it explicitly in the workflow; if there is no artifact or no configured registry, stop after the tag, the changelog, and the release rather than guessing. Support prerelease channels (1.0.0-beta.1) from a next branch. Explain the caret versus tilde ranges you write into package.json and the rule for what counts as a breaking change in our public API.