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).

Am 22.10.2020 um 17:50 schrieb Sönke Ludwig:
> with the drawback that there is no supported means to still provide something like a distinction between breaking (x) and non-breaking (y) changes.
* with supported I mean that you can use `~>0.x.y` to restrict to a certain x, which would be less obvious for something like 1.0.0-alpha.x.y.

On 10/21/20 10:47 AM, Robert burner Schadek wrote:
> https://code.dlang.org/packages/dsemver
> 
> is a program that computes the next SemVer for your dlang package.
> 

As indicated downthread, this could be a great ecosystem partner with dmd-as-a-library.

Thank you Robert!