This is why I don't use D.

[rikki cattermole]

On 06/09/2018 4:19 AM, H. S. Teoh wrote:
> On Wed, Sep 05, 2018 at 09:34:14AM -0600, Jonathan M Davis via Digitalmars-d wrote:
>> On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via Digitalmars-d
>> wrote:
> [...]
>>> And that is why I think we should implement my idea of putting *all*
>>> dub packages on code.dlang.org into our CI infrastructure, and log
>>> all successes / failures to a database that can then be used to
>>> display the range of version(s) of compilers that successfully built
>>> each package on code.dlang.org. Then people can quickly see, at a
>>> glance, whether the package still works with the version of the
>>> compiler that they're using (usually the most recent release, but
>>> not always, so this information can be super useful in making
>>> decisions).
>>
>> Oh, I think that that's a good idea, and it should help with folks
>> picking libraries to use, but it doesn't fix the fundamental problem
>> that whoever wrote the library needs to continue to maintain it or
>> pass it on to someone else to maintain it when they don't want to
>> maintain it anymore, or anyone using it is going to be screwed. So,
>> while your suggestion will definitely help with a piece of the
>> problem, it doesn't solve the part that I was talking about.
> [...]
> 
> Once packages are annotated with the last working compiler version, it
> will be an easy next step to identify all broken packages that need
> maintenance.  If there's an easy fix, someone could open a PR and push
> it upstream, or if upstream has abandoned the project, we could fork it
> and apply the fix.  Either way, CI automation would help us with the
> initial chore of identifying such packages in the first place.
> 
> Also, if the last working compiler version is prominently displayed e.g.
> in the search results, it will inform people about the maintenance state
> of that package, which could factor in their decision to use that
> package or find an alternative.  It will also inform people about
> potential breakages before they upgrade their compiler.
> 
> It doesn't solve all the problems, but it does seem like a good initial
> low-hanging fruit that shouldn't be too hard to implement.
> 
> 
> T

Alternatively we can let dub call home for usage with CI systems and 
register it having been tested for a given compiler on a specific tag.