There have been so many breaking changes in D that I've kept a few useful version checks in this gist: https://gist.github.com/SingingBush/3a2a6d2a41a81c1bafb26e5f69f823c0
for things like
static if (__VERSION__ < 2074) {
import std.traits : FieldTypeTuple, Filter; // Filter used to be in std.traits
} else {
import std.traits : FieldTypeTuple;
import std.meta : Filter;
}
and
// JSON_TYPE is now JSONType simply due to code style: https://issues.dlang.org/show_bug.cgi?id=19135
static if(__VERSION__ >= 2082)
import std.json : JSONType;
else
alias JSONType = std.json.JSON_TYPE;
this is one of my main problems with using D. There are breaking changes far to often. Generally with little to no overlap allowing time for developers to update code.
With GDC only supporting D 2.076 and the latest D release being 2.097 there's a whole range of D versions that dub packages should support if they are to work across all compilers. Sadly though, very few will work with a range of D versions that wide.
While ever this statement remains true; "D code written with latest dmd today may not compile with latest dmd in 12 months time", then D cannot really be considered for use by most organisations. This is the biggest problem with the D ecosystem