Computing the next SemVer for dlang packages with dsemver

[Sönke Ludwig]

Am 22.10.2020 um 10:59 schrieb 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.
> 

The real alternative to 0.x.y is 1.0.0-alpha.1+, though, with the 
drawback that there is no supported means to still provide something 
like a distinction between breaking (x) and non-breaking (y) changes.

There is also value in having some kind of indicator that the code has 
reached a certain level of maturity (1.0.0).