On Wednesday, 5 September 2018 at 06:16:57 UTC, Neia Neutuladh
wrote:
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh
wrote:
To me, this strongly suggests the following idea:
- add *all* dlang.org packages to our current autotester / CI
infrastructure.
- if a particular (version of a) package builds successfully,
log the
compiler version / git hash / package version to a database
and add
a note to dlang.org that this package built successfully
with this
compiler version.
Might be hard to definen what does it mean to "build
successfully". Many D packages love their metaprogramming, so
just building the package might be enough. Unit tests might even
pass, but when trying to use it in an application it might fail
in compilation.
I agree however that dub needs some mechanism of marking outdated
packages. I think it'd be healthy for D ecosystem in the long run
in general. There were a few times when I wanted to implement
some functionality, I was like "oh, there's obviously a dub
package for that". And there were, seven of them. Turns out two
were just an experiment, four didn't compile anymore (not
maintained since 2016), the last one worked, but I had to use a
git dev branch, because the one in the repository wasn't working
properly.
I commonly see an argument for putting things like logging,
serialization, archive support out of standard library and into
dub packages. I think it has some merit, but one of the main
advantages of having stuff in the standard library is that it's
commonly used and tested. I can expect std.experimental.logging,
std.zip to always work, because they are properly tested as part
of D release process.
