DScanner 0.12.1 stopped working

[Steven Schveighoffer]

On 7/5/22 2:47 PM, Carsten Schlote wrote:
> On Tuesday, 5 July 2022 at 17:52:37 UTC, rikki cattermole wrote:
>>
>> "libdparse": ">=0.19.2 <1.0.0",
>> "dsymbol" : ">=0.13.0 <1.0.0",
>>
>> > Restrict to a certain minor version: "~>2.2.13", equivalent
>> to ">=2.2.13 <2.3.0"
>>
>> That sneaky < condition at the end is more broad than what ~> is.
> 
> The current breaking change should bump the mayor number.
> 
> The minor number should mark backward compatible changes.
> 
> And the last digit should be bumped for all bugfixes, cleanups and other 
> stuff, which does NOT change the API at all (except of fixing it).
> 
> But even when we would use proper rules, it still depends on properly 
> setting up the new SemVer tags for Dub modules. Any mistake on this will 
> probaly break the code.
> 
> 

I don't know the context of how it's used, but changing allocators from 
stdx.allocator to std.experimental.allocator might be considered by some 
as not a breaking change.

D has a nasty habit of making everything a breaking change, because 
introspection is so good. So you have to draw the line somewhere. I 
haven't looked in depth at it, but if dscanner is using things that are 
implementation details, there is an argument to say that dscanner is the 
one that strayed from the public API.

But like I said, it can be fixed by making stdx.allocator an optional 
dependency of libdparse.

-Steve