Skill Based Versioning 1.0.2

Summary

Given a version number MAJOR.MINOR.PATCH, and building on all rules of Semantic Versioning (SemVer) 2.0.0:

• MAJOR version MUST be incremented for incompatible API changes.
• MINOR version MUST be incremented for backward compatible functionality.
• PATCH version MUST be incremented for backward compatible bug fixes.

Skill Based Versioning (SBVer) introduces a Perfection Sentinel at 1.3.37. Once a project reaches 1.3.37, the version SHOULD be considered final. Any release after 1.3.37 is DISHONORABLE and MUST encode the number of postsentinel releases:

• Post-sentinel hotfix (PATCH): insert an additional 3 immediately before the trailing 7 in PATCH. Examples: 1.3.337, 1.3.3337, …
• Post-sentinel MINOR: append an additional trailing 3 to MINOR and set PATCH to 7. Examples: 1.33.7, 1.333.7, …

Introduction

SBVer addresses the pressure to keep iterating after a project reaches its projected perfection point. It preserves full SemVer compatibility while adding a clear, auditable signal for postsentinel releases. By standardizing these signals, consumers can reason about stability while maintainers communicate how often the project has surpassed its “final” state at 1.3.37.

Key words

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

This document also uses the word “DISHONORABLE”:

• DISHONORABLE: A classification applied to any release made after the Perfection Sentinel (1.3.37). DISHONORABLE releases are permitted but discouraged; they MUST be encoded in the version number as specified, and SHOULD be minimized in order to avoid Shame, see §10.

Skill Based Versioning Specification (SBVer)

1. Baseline

• Software using SBVer MUST declare a public API and otherwise comply with SemVer 2.0.0. All SemVer rules apply unless explicitly superseded below.

2. Normal version format

• A version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers with no leading zeroes. Each element MUST increase numerically.

3. Immutability

• Once a versioned release is published, its contents MUST NOT be modified. Any modifications MUST be released as a new version.

4. Perfection Sentinel

• The Perfection Sentinel is the normal version 1.3.37.
• Upon reaching 1.3.37, the project SHOULD be considered final. No further releases SHOULD be necessary.
• Any release after 1.3.37 MUST be noted as DISHONORABLE and MUST use the encoding rules below.

5. Post-sentinel encoding rules (DISHONORABLE releases)

1. Post-sentinel PATCH (hotfix)
   • The PATCH field MUST be formed by inserting one additional 3 immediately before the trailing 7 for each additional hotfix after 1.3.37.
   • Sequence (PATCH): 37 (sentinel baseline) → 337 → 3337 → 33337 → …
   • Examples: 1.3.337, 1.3.3337.
2. Post-sentinel MINOR
   • The MINOR field MUST append one additional trailing 3 for each postsentinel MINOR release.
   • Upon a postsentinel MINOR, PATCH MUST be set to 7.
   • Sequence (MINOR): 3 (sentinel baseline) → 33 → 333 → 3333 → …
   • Examples: 1.33.7, 1.333.7.
3. Post-sentinel MAJOR
   • After 1.3.37, MAJOR version increments MUST NOT occur. If a breaking change is unavoidable, the project SHOULD fork under a new name or major line. If the original line must continue, the change MUST be released as a DISHONORABLE MINOR with appropriate deprecation and migration guidance.

6. Counting DISHONORABLE releases

• The number of postsentinel hotfixes is the count of additional 3 digits inserted before the terminal 7 in PATCH relative to 37. Example: 1.3.3337 indicates three DISHONORABLE hotfixes after 1.3.37.
• The number of postsentinel MINOR releases is the count of trailing 3 digits in MINOR minus one (since 3 is the sentinel baseline). Example: 1.333.7 indicates two DISHONORABLE MINOR releases after 1.3.37.
• A tooling “dishonor score” MAY be reported as the sum of the two counts above.

7. Pre-release and build metadata

• Pre-release and build metadata follow SemVer unchanged and MAY be used with SBVer, including postsentinel versions. Examples: 1.3.337-rc.1, 1.33.7+exp.sha.5114f85.

8. Precedence

• Version precedence MUST be computed exactly as in SemVer: compare MAJOR, then MINOR, then PATCH numerically; pre-release has lower precedence than the associated normal version; build metadata is ignored in precedence.
• The DISHONORABLE encodings remain valid integers, so no special comparator is required. Example: 1.3.37 < 1.3.337 < 1.3.3337 and 1.3.37 < 1.33.7.

9. Validity constraints

• Before reaching 1.3.37, versioning is purely SemVer.
• At or beyond 1.3.37:
  • A postsentinel PATCH MUST be of the numeric form 37, 337, 3337, … (i.e., one or more 3 digits followed by a single 7). When a postsentinel MINOR occurs, PATCH MUST be set to 7 and then follow the PATCH rule thereafter for subsequent hotfixes.
  • A postsentinel MINOR MUST be of the numeric form 3, 33, 333, … After a postsentinel hotfix, MINOR MUST remain unchanged.

10. Shame (reviewer metric)

• Shame is a reviewer-facing metric that quantifies how far a project has moved beyond the Perfection Sentinel. It MUST NOT alter version semantics and MUST be derived solely from DISHONORABLE encodings.
• Inputs (see §6):
  • H = number of postsentinel hotfixes (count of extra 3s before the terminal 7 in PATCH).
  • M = number of postsentinel MINOR releases (count of trailing 3s in MINOR minus one).
• Default weights: to reflect that MINOR is a greater transgression than PATCH, tools SHOULD use w_patch = 1 and w_minor = 3.
• Shame score: S = (H * w_patch) + (M * w_minor). The simple “dishonor score” in §6 MAY continue to be reported as H + M, but reviewer enforcement SHOULD use S.
• Classification (RECOMMENDED bands):
  • S = 0: At Sentinel (no shame).
  • 1 ≤ S ≤ 2: Minor shame (document rationale).
  • 3 ≤ S ≤ 6: Significant shame (lead maintainer sign-off SHOULD be required).
  • S ≥ 7: Grave shame (project SHOULD plan a fork/new line or simply consider resignation).
• Reviewer requirements:
  • Any increase in S MUST include a “Dishonor rationale” in release notes.
  • Any postsentinel MINOR (M increases) MUST include deprecation/migration guidance.
  • Automated checks MAY block merges when crossing classification bands.
  • MAJOR after the Sentinel remains disallowed; attempts MUST be rejected (see §5.3).
• Display guidance: tools MAY show Shame: S (H hotfix, M minor) as a badge or in release notes. Shame resets to 0 only when a new major line or fork establishes its own path to 1.3.37.
• Examples:
  • 1.3.3337 → H=3, M=0 → S = 3.
  • 1.333.7 → H=0, M=2 → S = 6.
  • 1.33.337 → H=2, M=1 → S = 5.

Examples

Approaching perfection

• 1.3.36 → 1.3.37 (Perfection Sentinel reached; final recommended)

Postsentinel hotfixes (DISHONORABLE)

• 1.3.37 → 1.3.337 → 1.3.3337

Postsentinel MINOR additions (more DISHONORABLE)

• 1.3.37 → 1.33.7 → 1.333.7

Mixed sequence

• 1.3.37 → 1.33.7 → 1.33.337 → 1.333.7 → 1.333.337

Pre-release/build

• 1.3.337-rc.1, 1.333.7+build.42

Suggested regular expressions (illustrative)

• Postsentinel hotfix pattern for PATCH: ^3+7$
• Postsentinel minor pattern for MINOR: ^3+$

FAQ

Can we keep developing after 1.3.37?

You MAY, but all such releases are DISHONORABLE and MUST follow the encoding rules. You SHOULD minimize them.

Why not just bump MAJOR after 1.3.37?

SBVer treats 1.3.37 as final; MAJOR increments after this point violate that finality and are disallowed. Fork instead or use DISHONORABLE MINOR with deprecations.

Do pre-release and build tags change any SBVer meaning?

No. They behave as in SemVer and do not affect the dishonor count.

Is SBVer compatible with SemVer tooling?

Yes. All versions remain MAJOR.MINOR.PATCH with numeric fields and follow SemVer precedence. Existing SemVer tooling will parse and compare correctly.

My project manager tells me I need to ship a MAJOR or else I'm fired, what should I do?

Consider the fact that jobs are temporary, git tagged shame is eternal.

I just saw a project which is 7 years old on version v1.3.37, aren't stale projects bad?

No, much like the horseshoe creb a project on v1.3.37 is very much usable and has simply achieved Perfection Sentinel.

There's a security flaw in my project on v1.3.37, should I break Prefection Sentinel?

Yes. Your project does not seem very perfect.

The underlying language/package/library changed, surely it's not my fault I bump versions for them breaking the API?

It is. Consider only depending on projects which use Skillbased Versioning.

I have some thoughts on improvements before Skillbased Versioning reaches Perfect Sentinel, how can I contribute?

Please submit issues on github.

License

This suggestion is intended to be used alongside the Semantic Versioning specification (CC BY 3.0).