On Wednesday, 5 September 2018 at 15:34:14 UTC, Jonathan M Davis
wrote:
On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via
Digitalmars-d wrote:
On Wed, Sep 05, 2018 at 09:18:24AM -0600, Jonathan M Davis via
Digitalmars-d wrote: [...]
> 3rd party libraries are usually the real problem if there is
> one. They need to be maintained, and if something happens
> that breaks them from one release to another, that can
> prevent you from upgrading until it's fixed - which may or
> may not be quick even if they're maintained. And if they're
> not maintained, well, then that's a serious problem. Now,
> that would be a big problem in pretty much any language, but
> the greater rate of change in D does make it worse than it
> would be in languages that change at a much more glacial
> pace.
[...]
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.
I have more radical proposition. Why not check regularly the
maintainers of a library querying for feedback. If no response or
negative response simply remove the package from the main list.
Put it in a section for unmaintained projects.
It would not change fundamentaly the state of the packages, but
would at least rein in on too high expectations.
OP would probably not reacted as badly as he did if he had known
that the package he tried was unmaintained.
This might reduce the number of packages available, but it is
often much better to have fewer choices than chosing the the
wrong one (or two or three).
