Considering it in the future, but not for the next academic year. We’re also hoping to use Jupyter for a scientific computing course in Python, so there are some external reasons such as integration with local systems that make it hard to move quickly. The Learn OCaml team kindly switched the license from AGPL to MIT earlier this year which brought it back into the running as a possible option for us which is hugely appreciated.
(To get this thread back on-topic to the original post) – it is most useful to have these style of hosted notebooks/client-side compiler platforms for teaching since we can centrally manage the version of the compiler being deployed and upgrade it fairly invisibly behind the scenes.
Main reasons I stay on older OCaml versions have been due compiler forks [MetaOCaml and Multicore OCaml for example]
For software that has to be widely distributed such as Coq we follow https://repology.org/project/ocaml/versions and usually require the minimum that makes it packageable for Debian / Ubuntu.
That cannot be. Ubuntu 18.04 (the latest LTS version) and Ubuntu 19.04 (the latest version) both provide OCaml 4.05. If you have OCaml 4.02.3, it means you’re stuck with Ubuntu 16.04 LTS, and it is time to upgrade to 18.04 LTS.
You are right on both points. It turns out that the machines run Ubuntu 16.04 LTS and it may well be time to ask for an upgrade.
For my personal projects, I’d always considered the Debian-stable OCaml package as a reference for the oldest compiler version to support in library code. The discussions in this thread suggest, however, that this approach is too conservative: teaching should use web-based platforms or an Ubuntu LTS, individuals most likely already use opam, and other developers probably have control over their release platform.
(I believe I speak for the Frama-C team, but take it with a grain of salt.)
Our industrial clients prefer changing versions as rarely as possible, so unless there is some really important feature or compatibility issue, we end up sticking with a given version for a long time. It also tends to minimize the amount of updates needed for our continuous integration.
That said, we will probably jump to 4.05 for the next release cycle (in 6+ months), which should help with some packages no longer available for 4.02. Due to the amount of “uncommon” features in Frama-C, we can rarely jump directly to the newest release, since there are always a few details to be ironed out (e.g. new warnings). We also track somewhat the Debian release version, as others have mentioned.
Interesting mention of ocaml multicore. Is using multicore even practical? I would imagine that very few libraries and ppx rewriters (if any) would work with it.
I use 4.06.1.
The pain when upgrading is that some opam packages are lagging.
I.e. not compiling or not installable with the latest version of the compiler.
One more example of having a separate opam switch for BAP with older OCaml and Core/Base libraries until recently, because newer OCaml switch required some changes in some libraries (safe strings mostly) that hold up an upgrade. Gladly it is fixed now, but caused a major inconvenience for integration with other OCaml code, written in a more modern fashion, thus requiring newer compiler and library versions. See BAP Pull Request #820 for more context.