I just realized that pcre2 (a package I maintain) doesn’t support OCaml < 4.12). [let’s not worry about how that happened, since it’s not relevant]. Most other packages I author and maintain, I keep compatibility for OCaml >= 4.10. And so, I wondered whether this was a problem: how often are people using OCaml 4.10/4.11 these days ? Is there a way to learn this ?
There is the method known as the ‘scream test’ 
3 Likes
I tend to follow the version of OCaml present in Debian stable (currently 4.13) but I don’t know how good that actually is. I’ll be following this thread 
BER MetaOCaml was at 4.11 till May this year, so until that time there was a strong reason to support 4.11. Now it’s up-to-date (4.14.1).
1 Like
I’m going to provide a slightly different type of answer but if you maintain packages in your free time for free, feel free to drop older versions (and even use only the latest one) whenever you feel like.
OSS already requires lots of work, and not all of it is exciting. I’d rather see more sustainable OSS practices when people spend their free time to grow in the direction they want instead of doing lots of ungrateful work 
Of course, nothing is wrong with trying to support more versions if you want to practice backwards compatibility, migration and multi-version support skills
4 Likes
Oh haha, the last time I asked this question that version was 4.10. Thank you for pointing this out! I feel much better now.
To get an overview of which distro has which package version (it shows a count next to the package version): ocaml packages dissection - Repology
To see which distro has which version: ocaml package versions - Repology
To see which distro is EOL when: https://endoflife.date/
To see what the effect of requiring minimum version 4.12.0 would be: https://repology.org/badge/vertical-allrepos/ocaml.svg?minversion=4.12.0
According to that list the latest version of OCaml in the very latest version of enterprise distros (e.g. Rocky Linux 9 which just got released last year) is 4.11.1. For users on those distros there isn’t a newer version of OCaml to upgrade to, unless they build it from source.
(Although enteprise distros usually contain outdated software on their release dates, I’m actually surprised to see Debian having more up-to-date versions than them)
TBH the responsibility for maintaining packages for enterprise distros is with the maintainers of those distros, and if your package is not present in those distros to begin with then I wouldn’t worry about supporting an old version until someone actually comes along and asks for it.
3 Likes
I vaguely recall seing a webpage visualizing red-green state of various OS distributions for opam packages.
Do we have a stats page showing all the CI (OS, distribution, version) targets and what percentage of opam repository packages pass for them?
@lukstafi > You’re probably thinking of the beautiful opam-health-check! It should be possible to play with the filters and stats at the top to compute how many other packages require >=4.12 (eyeballing the table, I was surprised to see that a number of packages even require >=4.14!)
2 Likes
It would be interesting to know if people are still working a lot with the ocaml compiler/libraries offered by Linux distributions, instead of relying on opam/esy/nix/…, and why. Could be a good question for the yearly ocaml survey.
It is probably a question of target audiences. As a developer I’m very happy with opam and the accelerated collaboration and development it has enabled.
However as an end-user I wouldn’t really want to bootstrap a compiler and build system for language $X in order to compile and use an application that is written in $X. (E.g. I use hledger and hledger-flow and getting it to use the system compiler or libraries is quite complicated as it is almost always too old even if I’m on a latest Fedora. And although a binary hledger package is available it happened to be a few versions behind the one that introduced a feature or bugfix that I wanted/needed. So I let it install a ghc + all dependencies itself, but it takes quite a while to build even on an otherwise fast box).
Having OCaml packages available in Linux distributions is a valuable way to attract new users. E.g. when I was trying to decide whether I should learn Standard ML or OCaml I looked at the packages available in Debian and there was a vast number of OCaml packages compared to Standard ML packages, so that told me that there are more people using OCaml for practical applications than SML (this was before opam existed).
Lately distributions have started to allow multiple versions of a package to be co-installed by suffixing the package name with a version number, or a separate package altogether.
There is devtoolset-11-gcc for RHEL-like systems where you want to use a newer compiler for your applications without recompiling the world. Similarly you can install both llvm14 and llvm16 because some packages depend on one or the other.
If there is a need for it one could envision both a default OCaml and an ocaml5x package backported (perhaps one that depends on devtoolset-11-gcc or newer to build) to older distributions. Similarly a newer version of Dune could be packaged in the same way.
That would indeed be a good question for the survey, because I don’t know how many users and developers are in this situation. E.g. as part of XenServer we rebuild OCaml 4.14.x on top of an otherwise ~CentOS 7 base, but I wonder whether we’re duplicating work here and someone else is doing the same as us without being aware of each other’s packages (well our package is almost the same as latest upstream Fedora + small build dependency tweaks).
2 Likes
You’re absolutely right about this! There’s a big difference between development environments and production deployments. In production deployments, you want binary packages installed by the OS-Native package manager. Only the very largest of organizations can afford to compilepackages from source; all the rest Need to use binary packages. And even those largest organizations will compile packages from source into binary packages And then install those.
1 Like