You seem to have specified several goals here and I am curious as to which one is the main or "true" goal. Are you looking to stop people debating over points 4 and 5? Are you looking to change projects which are in your opinion abusing this feature of semver, so that they release major versions? Are you looking to get fewer people using projects at version 0.y.z by indicating that they are not "public"? Are you thinking about this from a package-maintenance context like the semver maintainers are ("when is it safe to upgrade a package? never, if the first digit is 0.") or from some sort of other context, and what is that other context? I'd like to understand your needs better as I think anyone saying "this project implements semver" probably means that aspirationally rather than explicitly; they probably have shipped a breaking change with only a minor bump out of ignorance about some circumstance which is broken.

I'd also like to call attention to something of a larger question here, and it's along the lines of xkcd's "Workflow" comic: what I like about semver is that it makes some sort of oblique reference to a specification for how the software should work. One would want the specification to say that version 1.0.0 should be released when this specification has stabilized. Once we open dialog about specifications we start to talk about a sort of semver "formal semantics." And the reason that I'd be interested there, has to do with versioning something that is not explicitly depended upon by other software. For example, how might you apply semver to an app, or a game? Is a texture update "minor" or "major"?

So, what can we say about the formal semantics?

• A specification does not exist for 0.y.z releases. What is the most broad notion of a specification? Maybe this: that a specification should essentially concern "requests" and "responses" to those requests, and should state that certain requests are errors and certain information is guaranteed in a response. Those are approximately independent: "This is an error but I guarantee this sort of response" is the definition of a deprecated component, no? Then one could alternatively state that 0.y.z releases have the null specification: the one by which all requests are errors and thus any responses are formally undefined behavior. One could argue that maybe 0.y.z releases are all "deprecated" -- that is, there may be some sort of information guarantee but it may all be formally an error -- but I think that might be pushing the language too much.
• There are three sorts of software updates: (S) those that change only the specification, (C) those that change only the code, and (SC) those that do both. Semver as it stands right now demands that C-changes must only increment the patch version, while S and SC must at least bump the minor version and may bump the major version: which one gets bumped depends on the nature of the specification change; if requests that were formerly in error are no longer in error, or information is only added to the existing responses, or requests have been marked deprecated, we consider these "non-breaking" and increment the minor version. Any other change to the specification triggers a major version increase.
• There is a constant desire to add some sort of "generation" or "epoch" and thus transition semver towards PVP. One could state that this is a desire for a sort of meta-specification or "vision" of a product, the idea of specifying what direction the specification is evolving towards. "Foo solved the problem of TypeScript+OpenAPI routing for HTTP engines, but the core of the Foo engine is a TypeScript type evaluator that allows some types to be symbolic expressions which resolve into other types. Some people are depending upon all of Foo to use our type evaluator, even though they do not need the HTTP routing. We are releasing Foo2 which is ONLY the HTTP router, and Bar which is the type evaluator, splitting this into two packages." (I actually think that a formal semantics for semver would discourage adding this because it is much more nebulous to define in that way, but it's interesting to think about how one would formalize that sort of change.)

Just my two cents -- this very much only concerns the first bullet point but I see this question in that more specific context where one is trying to be clear enough to say what I think you want to say: "projects SHOULD release a version 1.0.0 as soon as there is any 'request' which should not be considered an error."

Thanks @crdrost, I've crossed out the section where my mind was rambling and the ideas didn't add to the discussion or make a strong point.

@ajbogh wrote:

I believe the intent is that anything pre 1.0 is considered "beta" software

No, actually that is not the intent. As the spec is worded, the product is to be considered unstable, as it clearly states. That is the only accurate label that applies here. Whether a product should be considered alpha or beta is not covered by the spec.

Unless you intend to issue a PR, or have further questions, please close this issue at your earliest possible convenience.

#547

When I publish SomeLib 0.1.0, I am saying to my potential user-base, here's some work product you may find useful, but I make no claims regarding its quality. The same is true for the entire series 0.1.0 through 0.9999.9999. It is not appropriate for the spec to say "the public should not use SomeLib because its authors wont release a 1.0.0 version". The spec declares the semantics in as few words as possible, and leaves it up to thinking people (even devs!) to decide what they should or should not consume.

I always advise people not to trust 0.y.z versions, and to do extensive testing if they consume such products, but I would not support any such language in the spec. I do not think it is our place to apply pressure on producers of 0.y.z versions of things, to apply more effort/resources to start releasing X.Y.Z versions of their products. There are many useful products available today, that would not be made available, if the producers were required to meet the full X.Y.Z semantics.

It is better for all of us, if these producers are encouraged to clearly mark their non-compliant products using one of the pre-release forms of version strings.

If we encourage consumers to shun 0.y.z versions, then such producers will likely begin emitting X.Y.Z-a style version strings instead. They are semantically equivalent and the -a provides no other semantic meaning than the spec implies, and it won't cause problems if they eventually release a -beta version.

I think that embedding our personal tastes in the spec should be avoided at all costs and strictly limited in the FAQ.