Applies Semantic Versioning 2.0.0 rules to decide version bumps and compare version precedence.
npx skills add https://github.com/DeepSpaceCartel/skills --skill semver-deepspacecartel
Please help me install this Agent Skill. Skill: semver Source: https://github.com/DeepSpaceCartel/skills/tree/main/skills/semver Command: npx skills add https://github.com/DeepSpaceCartel/skills --skill semver-deepspacecartel
-alpha.1 suffixes, +build metadata, and why build metadata is ignored for precedence. - Precedence and validation: Provides the full comparison algorithm with a worked ordering example plus the official validation regex for checking version strings before tagging. - Use Case: You are about to tag a release that removes a deprecated function. The Skill confirms this requires a MAJOR bump (e.g., 1.4.2 to 2.0.0), not a MINOR one, and reminds you that a released version is immutable. ## Quick Start Ask the AI to determine the correct next version number for your release given the changes since the last tag, using Semantic Versioning rules.High-intent search queries and answers about installing and using this skill.
Bump MAJOR for any backward-incompatible change, MINOR for backward-compatible new functionality or deprecations, and PATCH only for backward-compatible bug fixes. The decision is relative to your declared public API, not the size of the code change.
Compare MAJOR, MINOR, then PATCH numerically. A pre-release version has lower precedence than its release (1.0.0-alpha < 1.0.0). Pre-release identifiers compare field by field: numeric fields numerically, alphanumeric lexically, and numeric always ranks below alphanumeric.
No, build metadata after the plus sign (e.g., 1.0.0+001) is ignored for precedence. Two versions differing only in build metadata are considered equal, so strip the suffix or use a semver-aware comparison library before ordering versions.
Per the semver specification FAQ, start at 0.1.0 and increment MINOR for each pre-1.0 release. The 0.y.z range signals initial development where anything may change; tag 1.0.0 once a stable public API exists that users depend on.
No, a released version is immutable under Semantic Versioning. A bug found in 1.4.2 after tagging must ship as 1.4.3, because anyone who already pulled 1.4.2 needs a new version number to know something changed.
No, leading zeros are explicitly forbidden by the spec in MAJOR, MINOR, and PATCH segments, so 1.01.0 is invalid rather than merely unconventional. Use the official semver regex to validate version strings before tagging.
fjpulidopAudit API surfaces against stored baselines and generate migration plans.
skaile-aiAutomate changelog generation, version bumps, and annotated git tags for releases.
Pixel-Process-UGAnalyze staged diffs and generate conventional commit messages.
kabakaSchedule and enforce CalVer releases with automated changelog and git tag updates.