CODEWITHSUNDEEP
semantic-versioning
mgold
mgold

Reputation: 6366

Under what version is semantic versioning versioned?

Semantic versioning exists in two drafts (as of this writing, not counting betas and release candidates): 1.0.0 and 2.0.0. It is, apparently, versioned by itself.

Upvotes: 3

Views: 375

Answers (1)

jwdonahue
jwdonahue

Reputation: 6659

Those are great questions!

What is the breaking change between 1.0.0 and 2.0.0 that prompted the major version bump?

There were multiple changes that involved subtle tightening of the language in the spec and additions to the FAQ which likely prompted some code changes in some SemVer parsers (packaging and workflow tools), none of it very earth shaking. The biggest changes were:

  • Addition of #11 specifying version precedence, including prerelease tag and excluding build meta data.
  • Addition of the build metadata tag, which virtually guaranteed parser breakage in most if not all supporting products.
  • Removal of the 'v' from the version string.
  • Changes to the section numbers such that 1.0.0 #10 is not related to 2.0.0 #10, which definitely breaks reference links into the default semver.org page.

Do I need to be worried when using semver that this or future changes will cause confusion?

There's no standard way really to know whether MyCoolGizmo 1.2.0 is versioned under SemVer 1.0.0, 2.x.x or future x.x.x specifications. But then, you can't tell anything from the version string regarding any potential semantics, contracts or workflows, we'd need some sort of Version Meta/Schema (WIP) for that. There are a handful of proposals on the GitHub semver/semver issues tab that if adopted would be very disconcerting to many of us in the SemVer community, but are highly unlikely to be adopted in whole or in part.

I've had some email discussions with the maintainer regarding SemVer's future and have reason to expect that some planning is in the works to get some forward looking statements on record some time this year. A version 3.x.x may be somewhere around the corner, but that corner could be years out at this point. The standard has been quite stable and I am sure the it is likely to remain so.

EDIT: Getting to the core of your question, the semver.org site maintains "immutable" copies of five versions of the spec that can be referenced from your product documentation. I expect that list will grow as new release-candidates/releases are published. You should always be able to reference the version your products claim adherence to.

What would happen if semver made a change that was allowed under one version but not under others?

Any new version of SemVer will be relative to 2.0.0. Of course, any breaking change relative to 2.x.x is breaking relative to 1.0.0, so what's the difference? If you are concerned about features being removed, that's obviously a breaking change that would require another major version bump.

If you have any further concerns, you can ask them here or bring them on the SemVer issues site on GitHub.

Upvotes: 2

Related Questions