Policy on minimum supported OCaml version

[fsestini]

I would like to discuss our stance regarding the minimum OCaml version to support for herdtools7, which is currently 4.08.
In particular, to understand everyone's opinions on the reasons for keeping the minimum version to 4.08 as opposed to a more recent version, and what user populations we are intentionally trying to support with this fairly old version.

A few questions seem worth discussing:

• What is the reason for supporting 4.08.0 specifically?
• Do we have specific target environments or user bases that still need old OCaml versions and could not obtain newer versions through opam?
• Depending on which restricted environments we plan to support, how feasible would it be to support them by offering pre-compiled binary releases as opposed to keeping the source compatibility floor very low?
• Can we agree on a policy for when the minimum supported OCaml version should move? Just as an example: a policy that many projects seem to adopt is to support, at minimum, whatever OCaml version ships with the current Debian stable version.

CC @maranget @relokin @HadrienRenaud @artkhyzha

[maranget]

Hi @fsestini. Generally speaking I do think it is important to maintain compatibility with old versions first to avoid compilation problems at external sites but also to inform programmers about compatibility issues.

• I can answer your first question, even if this is not the kind of answer you expect! Before 4.08.0 we supported the "standard" old version (4.03 or 4.04 if I remember correctly). 4.08 saw the introduction of let*, which some of us used a lot and that brings a real benefit in terms of code concisness for monads.
• To the best of my knowledge we do not target any specific system or user base. Moreover using opam is almost mandatory to compile herdtools7. As a consequence, we are not really tied to some specific version because of some targetted systems or users.
• As to binary release I'd rather avoid them, as they introduce extra complexity. If appropriate I'd rather raise the floor, but not too high.
• The "follow Debian" policy is fine by me, Debian not being very keen on adopting the most recent versions. What is the OCaml version shipped with the current Debian stable version? Notice that I'd like to keep some 4.XX version as our minimal version because 5.0 was a major change in OCaml runtime.

[relokin]

I don't have a strong opinion but the argument whether we can raise the minimum version would become much stronger if we understood the impact on the codebase. Are there any major simplifications or features that would be enabled by a newer version of the OCaml compiler/library?

Depending on which restricted environments we plan to support, how feasible would it be to support them by offering pre-compiled binary releases as opposed to keeping the source compatibility floor very low?

As to binary release I'd rather avoid them, as they introduce extra complexity. If appropriate I'd rather raise the floor, but not too high.

I agree with Luc, from the little I've tried it wasn't very easy and I am not sure that it's worth putting a lot of effort. On the other hand if there is an easy to offer a binary release, in the past we were asked whether we could support a system that didn't have opam.

[HadrienRenaud]

Are there any major simplifications or features that would be enabled by a newer version of the OCaml compiler/library?

On a syntactic level, there are (almost) no differences between OCaml 4.08 and 4.14. There are a few introduced by the concurrent features of OCaml 5. There are some optimisations that are only available after later versions of OCaml (e.g. 4.14 brings TailModuloCons), so the only risk on earlier versions (e.g. 4.08) is running out of memory.

---

On the binary question, I just want to point out that @hrutvik implemented this for aslref in the static-binaries.yml workflow. More precisely, I think the workflow builds static binaries for all executables in herdtools, but only aslref is tested. My main question about this is how would libdir work (aslref ships its standard library in the executable).

[fsestini]

Hi @fsestini. Generally speaking I do think it is important to maintain compatibility with old versions first to avoid compilation problems at external sites but also to inform programmers about compatibility issues.

I agree with that in general, although in our case, our stance of effectively requiring opam as mandatory largely decreases the chance of those compatibility issues, as any system that can run opam can also install most ocaml versions via opam anyway.

• The "follow Debian" policy is fine by me, Debian not being very keen on adopting the most recent versions. What is the OCaml version shipped with the current Debian stable version?

The current stable version actually ships a fairly recent OCaml, to my surprise. This is the current situation for some of the major distros:

• Debian stable (13) is at OCaml 5.3
• Debian oldstable (12) is at 4.13
• RHEL/CentOS 9 is at 4.11
• RHEL/CentOS 10 is at 5.2
• Ubuntu LTS (24.04) is at 4.14

The OCaml version shipped by the various Linux distros can be seen on Repology.

Notice that I'd like to keep some 4.XX version as our minimal version because 5.0 was a major change in OCaml runtime.

That is a fair concern, especially given that the earlier versions of 5 did introduce regressions in (at least) memory performance. I believe those regressions have been fixed in recent versions though. In general, I think it would be good to set up some benchmarks to establish the actual impact of 5.* on our tools and have a better idea of which 5.* version could be a good candidate for a 4 -> 5 transition. (After all, at some point even the last version of 4.* will become too old.)

I don't have a strong opinion but the argument whether we can raise the minimum version would become much stronger if we understood the impact on the codebase. Are there any major simplifications or features that would be enabled by a newer version of the OCaml compiler/library?

That's a fair point, and I'm not sure I have a very strong or compelling answer to this. As far as I'm concerned, based on the kind of development I'm doing on herdtools7 right now, the advantages I would get from a more recent OCaml distribution are mainly from having a richer standard library. For example, I find myself often wanting to reach for the Either module, introduced in 4.12, or the modules for In/out channels, introduced in 4.14, in addition to various utility functions on strings, lists, etc. Whether having those modules/functions in the stdlib counts as a major simplification is probably subjective to some extent.

Unlike new language features, missing stdlib modules/functions tend to be less of a deal breaker, as we can often shim them by writing our own versions. However, these shims/workarounds still have non-zero maintenance cost, and this cost grows with the distance between our minimal version and the latest stdlib. Therefore, personally I would still advocate for a policy that keeps the minimum version conservative but also regularly moving and evolving with the broader ecosystem, even absent a must-have feature like let* or multicore that compels us to jump to a newer version.

Personally I like a policy that binds the minimum version to a specific set of distros (like the example I made with Debian stable, although it doesn't need to be that) as it makes the choice of "when do we move" easier and concretely grounded on a version that people are reasonably expected to be running at any given time. Of course such policy would not preclude reasonable exceptions and discussions.

Regarding the question of why raise the bar from 4.08 specifically: AFAICT from the Repology list above, there are no maintained distributions still shipping < 4.11, and opam-repository is also moving to 4.11 as the minimum supported version for its CI matrix for that reason. Therefore, I don't think it's really worth supporting anything below 4.11, regardless of what version we end up moving to.

I agree with Luc, from the little I've tried it wasn't very easy and I am not sure that it's worth putting a lot of effort. On the other hand if there is an easy to offer a binary release, in the past we were asked whether we could support a system that didn't have opam.

I think it largely depends on the target platform. Static builds for x86-64 Linux are definitely doable with some initial setup. The story may be very different on other systems though.

[relokin]

That's a fair point, and I'm not sure I have a very strong or compelling answer to this. As far as I'm concerned, based on the kind of development I'm doing on herdtools7 right now, the advantages I would get from a more recent OCaml distribution are mainly from having a richer standard library. For example, I find myself often wanting to reach for the Either module, introduced in 4.12, or the modules for In/out channels, introduced in 4.14, in addition to various utility functions on strings, lists, etc. Whether having those modules/functions in the stdlib counts as a major simplification is probably subjective to some extent.

Thanks @fsestini this is precisely what I was asking about, the features that we are looking to use and we can't and not so much all the available features that we are going to be available to us but we have no use for. To me that sounds like a good argument to require 4.14!

Personally I like a policy that binds the minimum version to a specific set of distros (like the example I made with Debian stable, although it doesn't need to be that) as it makes the choice of "when do we move" easier and concretely grounded on a version that people are reasonably expected to be running at any given time. Of course such policy would not preclude reasonable exceptions and discussions.

But then again these distros will also support opam, so if we assume that a user can install any package available from their package manager, opam will provide any version we chose to mandate.

Where I've seen users being heavily constrained are HPC systems. In HPC systems, users are limited to a module system which might or might not provide any ocaml version or opam. Usually users have to ask the HPC system administrators for specific modules.

[fsestini]

Thanks @fsestini this is precisely what I was asking about, the features that we are looking to use and we can't and not so much all the available features that we are going to be available to us but we have no use for. To me that sounds like a good argument to require 4.14!

I'd be in favour for moving the minimum to 4.14.

Personally I like a policy that binds the minimum version to a specific set of distros (like the example I made with Debian stable, although it doesn't need to be that) as it makes the choice of "when do we move" easier and concretely grounded on a version that people are reasonably expected to be running at any given time. Of course such policy would not preclude reasonable exceptions and discussions.

But then again these distros will also support opam, so if we assume that a user can install any package available from their package manager, opam will provide any version we chose to mandate.

You're right, if our stance is that "you need opam", then that's indeed the case. I guess what I meant is that in addition to our occasional revisions to the minimum version (which can be driven by "developer need"), we should also, I think, periodically sanity-check our version bounds against the ecosystem, to make sure the versions we support are still at least above the "obsolete" threshold. Tracking those distros is thus merely to get a metric of what constitutes "obsolete". This can be an informal, semi-regular check.

Where I've seen users being heavily constrained are HPC systems. In HPC systems, users are limited to a module system which might or might not provide any ocaml version or opam. Usually users have to ask the HPC system administrators for specific modules.

I am not at all familiar with HPC systems, but given what you say, maybe that's one platform that could potentially benefit from binary releases.