Computing the next SemVer for dlang packages with dsemver

[Robert burner Schadek]

On Wednesday, 21 October 2020 at 17:55:00 UTC, Sönke Ludwig wrote:

> 0.x.y vs. 1+.x.y is about the development process/state. Quite 
> often a design is not yet fully fleshed out in the beginning 
> and there are many incremental changes to the API. If 0.x.y 
> didn't exist, that would simply mean that either the project 
> gets more or less stuck with the initial (bad) design, or that 
> it quickly increments major versions, effectively providing no 
> more stability as in the 0.x.y case.

I think that is the one mistake SemVer does. 0.x.y is just one 
big loophole.
After the 1.x.y release an breaking api change requires a major 
version increment.
The way it should be. Stability or unstable is only mentioned in 
the 0.x.y
definitions.

You are not stuck on a bad design, break the api, improve the 
api, increment the major version number.
If you break the api in an 0.x.y version the hard part does not 
change.
In both instances the users have to update their usage.

In know in theory 0.x.y should be considered unstable. But by 
amount of 0.x.y we have you pretty much can't get anything done 
in D if you only use stable packages.
The loophole has become the normal case.

So what can we do, I see two major options:
1. we can live on the edge and use unstable packages and have no 
meaning in the
    SemVer number
2. we can acknowledge that most of them are stable, put a 1. in 
front and ignore
    the 0.x.y part of the SemVer definition and have the SemVer 
mean something

dsemver does 2.

And true there might be cases where dsemver does not increment 
the number correctly, but you can always increment by hand.

Also if your api is not stable after your 1.x.y release and you 
break everything in 2.x.y, so what. Your users are also annoyed 
when you break your api from 0.1.x to 0.1.1. Only difference is 
they could have seen in coming by looking at the SemVer.

I should stop ranting now.