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.
