ref-sp-dev-semantic-versioninglisted

# Semantic Versioning ## Purpose Provide portable defaults for assigning semantic versions and choosing dependency specifiers without drifting into version lock, version promiscuity, or misleading release numbers. ## When to use this skill - Choosing whether a change is a major, minor, patch, or prerelease bump. - Reviewing whether a release or dependency range is actually semver-compatible. - Deciding how to express npm or package.json dependency constraints. - Choosing between `dependencies`, `devDependencies`, `peerDependencies`, `optionalDependencies`, and `overrides`. - Explaining why a `^`, `~`, `x`, or exact range behaves differently than expected. ## Scope Boundaries - This skill owns version *numbering* meaning and dependency-range and dependency-field selection. - Use `ref-sp-dev-package-management` for the release workflow: version source of truth, multi-manifest sync, changelog policy, and registry publishing. - Use `ref-sp-py-commitizen` when the release is driven by the Python `commitizen` tool (`cz bump`, version providers, generated changelogs). ## Defaults - Use strict `MAJOR.MINOR.PATCH` versions with no leading zeroes. - Start from the public API, not from implementation churn, when deciding the bump level. - Treat `0.y.z` as unstable initial development where the public API is not yet stable. - Use prerelease identifiers such as `-alpha.1`, `-beta.1`, or `-rc.1` for releases that are intentionally not final. - Prefer ranges that match the actual co