[tchoutri]

Rendered version: https://github.com/flora-pm/flora-server/blob/adr-0003-compiler-version-and-tested-with/architecture/0003-compiler-versions-and-tested-with.md

---

Today, Flora displays a list of "tested with" versions on the page of a package.
This data comes from a raw version expression in the cabal file. Flora expands
this expression to a list of known GHC versions that is hardcoded in the
codebase.

This design has these problems:

• The hardcoded list lags behind the actual releases. It does not contain
  9.12.3, 9.12.4, or the 9.14 series. As a result, we get tickets on GitHub
  because a package page does not show all intended versions.

• The stored result is frozen. A new GHC release does not show on old releases
  until Flora imports them again.

• Open ranges expand to many badges. accelerate declares tested-with: GHC >= 8.6. Flora shows about 35 patch versions for it.

This ADR aims to fix this problem by reworking how we get compiler information and how the releases we import are linked to the compilers their claim to support.

[tchoutri]

@elland @leana8959 sorry to bother you, I'd just like your input about this ADR. :)

[benjaminweb]

tested-with:

• present:
  • up to date with current GHC version
  • not up to date:
    • inform the maintainer automatically to extend the test-suite and the tested-with information
• not present:
  • inform the maintainer automatically to provide tested-with information

I wonder how there could be some link between:

• GHC version defined in CI file
• result of CI (through API?)
• automatic derivation of tested-with information into some db whenever the CI runs

[tchoutri]

I do find the usage of get-tested to quite reliably enforce tested-with during CI.