Consider reducing the ocaml lower bound to 4.11

[shonfeder]

The minimal required version to build ocaml was raised to 4.14 in #13533 and released in 3.23.0

However, concerns were raised on discuss in the release announcement by @kit-ty-kate, who has also helped us understand the known and possible negative impacts on user:

The main concerns I'm aware of are:

1. Being out of sync with the opam-repo's compiler cutoff threshold (currently 4.11)
2. It will prevent opam from keeping their "vendored" dune dependency up to date, or else requiring they maintain a fork.
3. It's expected users on older distributions may suffer.
4. It has required adjustments to Js_of_ocaml: Switch to dune 3.23 ocsigen/js_of_ocaml#2231

[shonfeder]

We discussed this at the dev meeting today. Here's my summary:

• @rgrinberg was strongly against reverting, and thinks we have nothing to gain by going back to 4.11.
• We discussed the concrete impacts noted above (for opam and jsoo), with Rudi's view being that if project (including opam) wants to vendor a version of dune that supports older versions of the compiler, they may need to take on the maintenance burden of that backward compatibility.
• I asked what are the critical needs that makes it necessary to update to 4.14, and there are apparently none. However, the overall maintenance drag reduces our ability to improve dune and our support for platforms.
• E.g., Rudi pointed out that getting real first class support for Windows should be higher priority that maintaining backward compat for compiler versions that aren't maintained any longer: resources are finite, so we have to chose where our maintenance budget goes.

Our conclusion was to invite reports of any other concrete, negative impacts of the lower bound increase. If we find there are significant negative impacts, we could justify moving forward with #14502 . Otherwise, we may need to coordinate with opam to find them another alternative for their vendoring concern.

[shonfeder]

I think it make sense to just move forward with 3.32.1 now, without waiting go get this in. The added support for the secondary compiler, and the other fixes are useful independently, and we can release 3.23.2 if we end up gathering evidence to justify rolling back to support 4.11

Do you agree, @Alizter? Or do you propose another way forward?

[Alizter]

@shonfeder I've added another regression to the list you should consider. Regarding 4.11 I agree let's not do that now.

[rgrinberg]

I'll just add a few points:

Being out of sync with the opam-repo's compiler cutoff threshold (currently 4.11)

We were never in sync with their policy. Dune still has an official policy of supporting the latest 3 versions of OCaml. It was relaxed for the 4 to 5 transition, but I see no reason why we wouldn't go back to it once the transition is over. The opam repositroy is a completely different project with its own resources, constraints, and vision. It was never our goal to follow them.

I sympathize with the concerns regarding supporting old versions, but I've yet to see a user report with substance. I'd like to see reports explaining their situation and why they absolutely must use an ancient version of OCaml and compile dune with it despite the endless workarounds. Yes, this might be an inconvenience, but it is also a tremendous maintenance burden for the dune team.

I asked what are the critical needs that makes it necessary to update to 4.14, and there are apparently none. However, the overall maintenance drag reduces our ability to improve dune and our support for platforms.

While this statement is true, it is also true for 4.08 and probably even earlier versions than that. OCaml is an old and stable language, and rarely there's anything new that we absolutely must have. The goal here is not to jump on to some new features, but to reduce the maintenance burden which I argue is:

• Disproportionate given the number of users it benefits
• Takes away from far more important maintenance work.

Let's focus our resources on providing true support for the platforms we claim to support, and think of ways we can take advantage of new versions of OCaml to improve dune.

[shonfeder]

Dune still has an official policy of supporting the latest 3 versions of OCaml

Do you know if that policy is documented? I haven't found it in a quick search.

We were never in sync with their policy.

Yes, I didn't mean to suggest we fell out of an intentional sync, but there is apparently pain felt by the lack of sync! It has also happens that we have been in sync by chance since the (relatively recent) addition of the cut off threshold.

I'll rephrase this issue so it can be a landing place for possible additional reports, and I propose we close this after roughly 3 months if they are not forthcoming. Does that sound like an OK plan?

[rgrinberg]

Here's a reference to it from the meeting notes: https://github.com/ocaml/dune/wiki/dev-meeting-20191126

I didn't look very hard, but there are endless discussions around in the slack channel as well

I'll quote something from the plans of the dune 2 release as well https://github.com/ocaml/dune/wiki/dev-meeting-20190704

In order to keep the development of Dune dynamic and keep the project modern, we want to switch to a mode where we move freely to new compilers as they are released. In particular, we plan to require OCaml 4.08 to build Dune 2.0.0. By switching to this mode, When multicore becomes available in OCaml we will be able to take advantage of it immediately.

It's a shame that these plans got derailed, but I would like to resume them and invite everybody to start thinking about how we're going to make this transition. Your help would be much more appreciated here.

I'm OK with keeping this open to hear in what contexts dune is not usable to them.