@xavierleroy recently observed the madness of well intentioned open source crowds: Right, we stopped supporting native-code compilation to 32-bit architectures in OCaml 5, but we’re good people, so we committed on maintaining OCaml 4 for the forseeable future, including all its 32 bit code generat…

I agree this is a good move, thanks! (I think that upstream should probably clarify that this means that arm-32 (and probably x86_32) is not maintained anymore, even on the long-term 4.14 branch.)

[image] gasche: I think that upstream should probably clarify that this means that arm-32 (and probably x86_32) is not maintained anymore, … except on bytecode? I’m a little fuzzy on this matter, but 32-bit OCaml is used in JavaScript and wasm compilation right now.

[image] avsm: I’m a little fuzzy on this matter, but 32-bit OCaml is used in JavaScript and wasm compilation right now. Right. I’d love to go 64-bit only, but currently and for the foreseeable future 32-bit processors are still supported by the OCaml bytecode compiler and runtime system, to…

Re: dropping some OCaml versions from OPAM CI, I think it’s a good idea to save on electricity and to make CI reports shorter and easier to process. Concerning which OCaml versions to support, Debian is currently at 4.13 (oldstable), 5.3 (stable), and 5.4 (testing). RHEL/CentOS 8 is at 4.07 (too o…

Thanks! I’ll add 4.11 as you suggest and trim some of the compiler variant combinations (and perhaps remove things like flat-float-array as they are quite specialist).

[image] avsm: Does anyone use flambda+fp? One seems to give performance, and the other taketh away. I use this combination locally for some projects, but no need to keep it on my behalf. I take exception to the suggestion frame pointers takes away performance :slight_smile: it gives nice tool…

[image] lambda_foo: I take exception to the suggestion frame pointers takes away performance :slight_smile: it gives nice tools to improve OCaml performance. My benchmarking on ARM64 showed no difference between FP and no-FP, I don’t think anyone has done comprehensive benchmarking on AMD64 rece…

[image] avsm: 4.08 (the lowest bound) looking at repology, it seems that Ubuntu 20.04 is the only distribution still using OCaml < 4.11 and since, by chance, Ubuntu 20.04 is actually getting EOL at the end of the month, i think it might be the perfect time to also bump that lowest bound for o…

correction: EOL (for non-paying customers) was one year ago. Even more reason to do it

I do appreciate going to 4.11 as lower bound, and archiving packages that require earlier OCaml releases. If you like, I can get back to my scripts to prepare lists of packages that would be archived under this assumption. It would as well be beneficial to state a policy in the opam-repository whic…

Dropping some intermediate OCaml versions from CI

Ecosystem

hannes April 9, 2026, 7:39am 13

Taking 4.11 as the lowest OCaml version would result in the archival of: see https://discuss.ocaml.org/t/archival-ann-raising-the-ocaml-lower-bound-to-4-11-0-for-opam-repository/

Topic		Replies	Views
Raising the minimum tested version of OCaml to 4.05 or 4.08 (from 4.02) Community opam	12	1391	July 6, 2023
Which OCaml compiler versions should we run against in CI? Ecosystem compiler , ci	2	813	May 29, 2021
Docker base images and OCaml-CI support for OCaml < 4.08 Ecosystem opam , compiler , announce	1	177	March 6, 2025
Unsupported ocaml versions (any policy)? Community	9	1037	February 7, 2023
Supported range of OCaml compiler Ecosystem opam	12	1293	June 1, 2018

Dropping some intermediate OCaml versions from CI

Related topics