haskell
Rank package search results by latest GHC supported
Is it possible to add "latest GHC supported" as a ranking factor?
Several times I had a very frustrating experience, when I clicked the first search result, assured myself that the package fits my requirements, spent some time learning API (and liked it!) - only to discover later that the latest supported GHC is roughly 7.10.
I do not know technical details: is it easy to extract "latest GHC supported" metric from Hackage Matrix? Maybe "upper base bound" may serve as a good approximation, if it is easier to access.
The idea of having last upload date in the results (and being able to sort by it) is supposed to be a proxy for that. Does that not suffice?
That said, whether we rank by it or not, having an explicit representation of last base upper bound in the search results might be helpful.
Does that not suffice?
Not really. It is quite possible that the package is small/simple enough to work with recent GHC without changes for a decade.
Also, last upload date does not reflect last revision date. Showing last revision date will be ambiguous as well: there are both revisions, relaxing base bounds (like, a maintainer checked that a package is compatible with a newer GHC), and revisions, which restrict them (like, a Hackage trustee noticed that a package is not compatible with a newer GHC and changed base < 5 to base < 4.13).
is it easy to extract "latest GHC supported" metric from Hackage Matrix?
Fwiw, there's already a badge shown at each package, such as e.g.
the long-term plan for it is to have it express a build-plan quality/health metric (such as support for recent GHCs as well as not failing); we can encode various things into a graphic representation that fits into a badge
...and in principle we could make the search-result include such a badge for each result row
would that help?
That said, whether we rank by it or not, having an explicit representation of last base upper bound in the search results might be helpful.
Btw, for that to make sense we should filter out/ignore the meaningless base < 5 bounds which provide no information and thus would merely reduce the signal/noise ratio. And you need to be a bit smarter than merely look at the most recent release to infer the compat range (I have a few examples where this would break down completely and give the wrong impression)
...and in principle we could make the search-result include such a badge for each result row would that help?
Certainly.