mirror of
https://github.com/semver/semver.git
synced 2026-03-09 07:22:04 -05:00
Definition of "stable" #140
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#140
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 @RWOverdijk on GitHub (Jul 16, 2014).
Hello community!
I'm going to toss in my opinion on something, and will probably see some pushing back. I disagree on the way "stable" is being described:
And
Besides the obvious grammatical error (you should be 1.0.0), I believe this to be false information. As stated at the top of the document:
This implies that 0.1.0 could be considered stable. You start off at 0, and as long as you don't change the initial API, there's no need to bump a major version. Not even when making the API public, because that's not an incompatible API change.
It is true that almost nobody gets it right on the first try, and they'll most likely mess something up, causing a major version bump, but this means that they were public and stable to begin with. In reality, any tag must be considered as stable. Until it is, it's either a branch, alpha, beta or RC.
So I suggest either changing the MAJOR version rule, or the stable rule into something less restrictive.
Please don't kill me. :)
@FichteFoll commented on GitHub (Jul 16, 2014):
Semver is particularly aimed at resolving and specifying dependencies. Both occurences of
stabledo not refer to the "stability", or bug-freeness so to speak, of your product, but to whether or not the API will remain the same for all versions in that version range.So no, this is not false information, but yes, I do think something regarding "What is a stable API?" should be added to the FAQ, especially since this issue came up a few times recently.
@RWOverdijk commented on GitHub (Jul 16, 2014):
Fair enough. So, in theory, if you have a set api that's public and doesn't change for the entirety of the 0.x major version, it could still be considered as a "stable" version (not talking about the bugs)?
Thank you for not idiot-shaming me. :)
@FichteFoll commented on GitHub (Jul 17, 2014):
Yes. You can, for example, add new features with new minor releases but you may not remove functionality or introduce other backwards incompatible changes - without increasing major.
The 0.x.y version state has an exception clause because software is likely to undergo rapid changes during that time, so that establishing a "public api" that you want to preserve is not worthwhile because you would increase the major version far too often.
@RWOverdijk commented on GitHub (Jul 17, 2014):
Got it. One of my APIs is at 0.3.1 and has been at 0 for a year now. I just wanted to make sure I wasn't doing it wrong. I'm happy to know I wasn't.
@rlidwka commented on GitHub (Jul 17, 2014):
jade was at 0 for more than a three years (Jun 2010 - Dec 2013) and reached 0.35.0 before the 1.x release.
A lot of stable programs we use in production are still at 0.x. It's a standard practice apparently, to comply with semver, but at the same time avoid all the trouble with majors.
@jwdonahue commented on GitHub (Dec 6, 2017):
@RWOverdijk, it has been my experience that in most cases, my customers have come knocking on my door wanting me declare a 1.0.0 version so they can also do that. It's essentially, a milestone marker plus a promise not to break anything in the future without bumping major again, or adding a prerelease tag. As long as your customers are willing to go along with your dwelling in the 0.x.x ranges, you are absolutely free to do so, but you should also be aware that 0.x.x transmits the idea that literally anything could change on the next patch bump.
Unless you have further questions, please close this issue at your earliest possible convenience.
@RWOverdijk commented on GitHub (Dec 6, 2017):
Yeah, I still use it as intended. I the first push of code doesn't have BC breaks I don't bump to 1. So far that has worked fine. So I'll close this.