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.
