DScanner 0.12.1 stopped working (page 2)

On 06/07/2022 5:48 AM, Steven Schveighoffer wrote: > On 7/5/22 1:30 PM, rikki cattermole wrote: >> >> On 06/07/2022 12:56 AM, Carsten Schlote wrote: >>> So the question should be, why a breaking change slipped into mainline. At least it is impossible to build the dub package now with any of the current compilers. >> >> What happened is that WebFreak created the tag v0.19.3 which is automatically upgraded to. Rather than v0.20.0 which wouldn't have been. > > Nope. > > https://github.com/dlang-community/D-Scanner/blob/e639f8bcbe8a73c9ebefb445edc101ec0c2731c1/dub.json#L15 > > > -Steve "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.

July 05, 2022

Re: DScanner 0.12.1 stopped working

Posted by Steven Schveighoffer
in reply to Carsten Schlote

Permalink

Steven Schveighoffer

Posted in reply to Carsten Schlote

Permalink

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

On Tuesday, 5 July 2022 at 19:03:03 UTC, Steven Schveighoffer wrote:

On 7/5/22 2:47 PM, Carsten Schlote wrote:

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.

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

-Steve

I've been hurt numerous times over the years by breaking changes in D so started maintaining a list of version checks that have been helpful in keeping projects compile with multiple language versions.

https://gist.github.com/SingingBush/3a2a6d2a41a81c1bafb26e5f69f823c0

It would be great if more packages in dub repo used such mechanisms.

Forums