Opinion: Is it time to stop testing with opam < 2.2

Ecosystem
,
1
1 Like
2

Contrary to Betteridge’s law of headlines I will answer: yes.

I’ve been using the containers a bit and they work well until you get a strange failure where OPAM can’t do something. Then it usually turns out that the reason is because the default opam is 2.0.x which came out about 9 years ago and doesn’t support a lot of the flags.

Then you need to learn that there is in fact newer opam available in the containers and that everyone symlinks newer versions to the opam binary usually.

Thus for the pure avoidance of footguns, just drop 2.0. And 2.1 can go as well (despite being in Debian stable). Are there a lot of packages that work on 2.2 and don’t work on 2.1? I don’t think so. And for everyone doing development with OCaml they are probably running newer distribution versions like Debian testing or can just install a prebuilt binary from the OPAM website. It really isn’t much of a hassle.

1 Like
3

In my opinion the article mixes up 3 different things:

  • archive-mirrors not having the right priority with opam < 2.2: this could be simply added to opam-repository’s repo file today. I don’t think anyone serious would be using a local mirror with opam 2.1. If someone is, this could be simply warned as a custom announce if the user is using opam < 2.2 but i’m not sure it’s necessary.
  • Stop testing opam-repository with opam < 2.2: this one i don’t think is a good idea just yet. Sadly opam 2.1 is still in use in the wild (see repology) and testing should take into account what users actually use in my opinion. I don’t really have a good answer for the solver timeout with opam 2.0 but maybe errors like that could be ignored since 2.0 is the least used.
  • Stop generating docker images with opam 2.0 as default + the binary for every major opam versions: this is your choice if you want to change the image matrix. My 2 cents is that having the full matrix of images with just the latest version of opam (+ latest beta and master) is reasonable, but there should at least be one <distribution>-opam-<version> generated for the latest versions (LTS & latest) of the compiler for continued testing on opam-repository (see point 2). Given this would be a breaking change, the naming system could maybe be changed or something like that, so that users of those images don’t get their setup broken out of nowhere.
2 Likes
4

I don’t know what the answer should be but:

What are users actually using? To look at the first line in the link, how do we know if user of Alpine Linux 3.15 really use opam and use it on the version of their distro and don’t bring something newer?

LTS policies are a (sometimes commercial) decision of the distribution, we can’t expect all opensource project to follow suits. I’m not expected anyone to give much thought to opam 1.x because it’s still part of some Ubuntu LTS.

1 Like