mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #734] The myth that releasing version 1.0.0 implies any type of long term support #4736
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#4736
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @fulldecent on GitHub (Jul 26, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/734
In one widely-used project we are discussing whether to release version 1.0.0.
Some opposing viewpoints cite that version 1.0.0 has some implicit representation of quality or completeness. Or that making a major version release implies that there will be long term (permanent?) support for that release.
I think the 1.0.0 question of SemVer is one of the most important questions. So I love to hear any of your experience on these topics.
An instance of this kind of discussion: https://github.com/ethereum/solidity/issues/11690
To make this discussion into an implementable product change: if this is a frequent discussion point, can we make it part of the SemVer FAQ, ordered appropriately based on how frequent this question or sticking point is?
@axic commented on GitHub (Jul 26, 2021):
In the referenced thread this is explained with a bit more nuance. The referenced compiler language project has made over 90 releases with
major0, but not making breaking changes unless bumping theminorversion. As a result it had so far 8 breaking releases and over 80 non-breaking releases. With this background, a sudden change tomajor1 does imply a lot more calcification, and in turn long term support.Perhaps this just shows that SemVer is a bit tricky for programming language projects. I do think a major version release implies that the language remains fully compatible within that major and that major will be supported for a longer period of time.
@ljharb commented on GitHub (Jul 26, 2021):
No, it does not necessarily imply that. Numbers are numbers. 1.0 implies no more length of support than any other number.
@lucasgcb commented on GitHub (Aug 2, 2021):
According to semantic versioning, when going from 0.x to 1.0, it suggests that scripts under 0.x versions will be incompatible with 1.0 API, and vice-versa.
That is it.
It does not imply anything other than breaking changes. It is as much quality or long term support as any other version increase.
I find that the implicit representation of integers such as "1.0" or "2.0" (two-point-oh!) having the idea of largely superior quality is attributed to the liberal use of the Mark system in pop culture, where a scientist pulls out a robot saying "here's von neumann Mk II!" and it goes from being a just dust roomba to a demigod of cleaning.
Realistically, a major version can increase on a bugfix that may call for rework for everyone using the API; major bumps are largely meant to communicate a bad thing in general. New features that don't break anything in Semantic Versioning simply go up as minor versions.
@jwdonahue commented on GitHub (Aug 12, 2021):
For any sequence of
0.y.zversions, every single publication is potentially breaking. Any claimed adherence to bumping minor on breaking changes is ignored by all SemVer compliant tooling. The assumption is, the publisher is not willing to make any claims of backward compatibility for any point release, until they get to 1.0.0. All following, non-prerelease publications, MUST follow the full semantics of the standard wrt the version tripple.This does not preclude immediately reverting to a very long procession of prerelease publications, including many breaking changes.
All prerelease versions, no matter their form (
0.y.zor-pre), are potentially breaking changes. When you finally get to anX.y.zwhereX > 0, you are simply laying the ground-work for subsequent non-breaking changes. Until then, it is impossible to communicate any non-breaking change commitment via the SemVer semantics. Few, if any automation, recognizes any side-channel communications. So as long you are hiding behind0.y.zversions, or any prerelease tags, it is not possible for standard tooling to automatically pick up any critical bug fixes you might wish to push into your ecosystem.Using full SemVer semantics is considered a best practice. If you have the quality controls needed to predictably release non-breaking changes, then you should do so whenever possible. You just can't do that with either of the SemVer prerelease versions.
@ljharb commented on GitHub (Aug 12, 2021):
@jwdonahue the first part isn't entirely accurate; all of npm uses an older version of semver which says that in
vX.Y.Z,v0.X.Y, andv0.0.X, the X is major, the Y minor, and the Z patch, and that's what the entire JS ecosystem uses.@jwdonahue commented on GitHub (Aug 13, 2021):
@ljharb What exactly about what I said isn't accurate? Does NPM do the major-shift-to-minor, non-SemVer thing for the
0.y.zprerelease forms? Or are you referring to the beta version of the spec that allowed thevprefix, which seems irrelevant to this conversation.Addenda, I think I see it now. My zero looked like a capital O until I put it in code markup.
@ljharb commented on GitHub (Aug 13, 2021):
@jwdonahue im referring to 0.x non-prerelease versions; in the npm ecosystem and an earlier version of the semver spec, it is not “everything below v1 is always breaking”. Prereleases in the npm world thus work the same wrt their non-prerelease version pre-1.0 as post-1.0.
@jwdonahue commented on GitHub (Aug 13, 2021):
That's an NPM extension to SemVer. I don't think it was ever codified in a release version of the standard. If it was, a reference would be appreciated. In a SemVer compliant mode, NPM should treat all
0.y.ztriples as indicating possibly breaking changes. I've never been a fan of NPM or Java, so I don't have much experience with it, but I do recall reading that NPM has a SemVer compliant mode. I for one, would never allow automation to accept any0.y.zversion bump without manual intervention.@ekpyron commented on GitHub (Aug 13, 2021):
For the record: historically, for whatever reason npm's semver implementation went for
ea1b9e370e(from what I can tell contrary to anything the semver spec ever said and as a conscious choice towards ignoring the precise wording of the spec: https://github.com/npm/node-semver/pull/41#issuecomment-21354034) and then oscillated back and forth on that a few times to finally weaken it back toMany authors treat a `0.x` version as if the `x` were the major "breaking-change" indicator.(ind89ba57951). That's probably the source for the tendency of that ecosystem to not strictly comply to the semver spec in that regard.@jwdonahue commented on GitHub (Nov 30, 2021):
All five published versions of the spec have the same wording:
All prerelease versions should be treated by consumers as breaking changes. The fact that some tools apply other conventions to similar looking version strings, does not imply any relation to SemVer. There are many schemes that use version triples, and most have some form or other semantics around them, but they are not SemVer. If a publisher says their 0.a.b version string is SemVer, then it should be treated as a potentially breaking prerelease version.
@IPMHERO commented on GitHub (Nov 25, 2022):
Cảm ơn
@spamthroat commented on GitHub (May 26, 2026):
I came across this when seeing if something we did in a company I used to work for was a 'real thing' or just them.
They used letters instead of the .
so r - release, t - test, d - development so 1d0 was the development number, 1t0 was the frozen test version and 1r0 was the release version.
There could be a second letter for a special release for one customer or a beta release so 1r0s1 or 1r0b1
So the letters denotes the status and not the number.