Computing the next SemVer for dlang packages with dsemver

[Sönke Ludwig]

Am 21.10.2020 um 16:47 schrieb Robert burner Schadek:
> https://code.dlang.org/packages/dsemver
> 
> is a program that computes the next SemVer for your dlang package.
> 
> It uses a slightly modified SemVer definition.
> 
> It does this by using the -X flag for dmd to get a json file of the symbols
> and then compares them to the most recent git tag that resembles a SemVer.
> 
> First release is 1.0.0.
> If a symbol is removed or its signature changed the major version is 
> increment
> and the minor and the bugfix number reset to 0.
> If a new symbol is added, the minor number is incremented and the bug fix
> number is set to 0.
> If all symbol stay the same the bugfix number is incremented.
> 
> In an ideal world the dub registry would use this to compute the SemVer 
> for you,
> but baby steps.
> 
> I hope to see many bug reports and PRs.

There are cases where a symbol change is not a breaking change in 
practice (maybe splitting up a function into two separate overloads) and 
where no symbol change is required to produce a real breaking change 
(e.g. a compile-time logic change within some template). In my 
experience it is often a judgement call where to draw the line, even 
sometimes deciding between a patch release and a major release.

Of course, theoretically *any* change that is not backed by a 
preexisting specification is a breaking change in one way or another, 
especially when D's introspection or runtime behavior come into play...

Anyway, I think this can be a very useful diagnostic tool to avoid 
accidental introduction of breaking changes at that level, and maybe 
also to actually generate new versions in certain contexts. However, I 
definitely don't see this as a potential feature of the registry in the 
sense that it automatically creates new versions for all packages.