v0 versions have no patch number.

Hi @ljharb,

v0 versions have no patch number.

So, are you saying that the superset rule is not applied in the initial development. If so, what is the point of work with 0.Y.Z. Why would we need to have Z releases if we can distributed to them new features and breaking changes at the same way that we can do with 0.Y releases?

Also, if so why suggest init the project with 0.1.0 and not 0.0.1 ?

How should I deal with revisions in the 0.y.z initial development phase?
The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

PATCH version when you make backwards compatible bug fixes

Ideally you'd start the project with 1.0.0 and avoid v0 versions entirely :-)

Hi @ljharb,

Thank you for your replies. Let's try to discuss this one in : #915 where we can keep all thoughts centralized.

I have a problem with:

The public API SHOULD NOT be considered stable.

Okay, so the API can change but breaking changes in the implementation aren't allowed?

And this is contradictory:

0.Y.Z releases still reserved to backwards compatible bug fixes.

Which is it? Stable or not stable?

It's a prerelease, therefore all bets are off with regard to the meaning of any of the fields in the triple.

This phrase from the 9th clause makes sense to me:

A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

The "and might not satisfy compatibility requirements..." part of that, tells me what I need to know about "unstable".

So why not just drop clause 4? I think that is what was suggested by @stevelabnik in #915.

In any case, messing around with how prereleases are detected and what they mean is a breaking change.