In my experience the biggest issues with upgrading versions have been ppx_deriving (or its other plugins) not being up-to-date for the newest OCaml release (and even when master has a fix there is no release for a long time as happened with this commit).
So usually we are either on the current version or are one version behind. We don’t tend to use beta versions of the compiler since that basically guarantees that there will be some dependency that will prevent us from compiling.
I’m not held back. Orsetto dropped its dependencies on everything that isn’t yet ready for OCaml 4.08, and I’m adopting a new rule that PPX rewriting will never be required with whatever is the latest release of the compiler.
This time another big obstacle to upgrades is the many new deprecations that prevent code that uses Pervasives (or Yojson.t in a similar vein in the ecosystem) that kills normal dune projects in dev. So in my experience so far, I have to do some work for my librairies to compile cleany in dev mode on both 4.08 and older versions (using dune to generate shims, etc.).
So I’m almost done upgrading. The main blocking “issues” are:
--keep-locs is now the default and we do shady stuff 
Some feedback about non blocking issues:
-unsafe-string for some files~f: or ~f: changed to `~compare:~The lab machines we use for teaching are based on Debian stable which means that the default OCaml compiler is currently 4.02.3 (soon to become 4.05.0, if I understand correctly). Installing opam to use a more recent version requires (1) an additional technical step and risk of confusion for beginners who sometimes already express a preference for a more familiar programming language and (2) a certain amount of disk space in student home directories mounted from a network share.
Maybe this does not matter. For such introductory courses, there is probably little need to use the latest compiler and related packages. Do other people have similar issues when using OCaml for teaching?
Unrelated to OCaml, but during teaching reverse engineering with radare2, Debian-based distributions are always a big pain, since always there is a someone who uses ancient version from the packages. Of course you can’t compare radare2 and OCaml infrastructure due to the sheer size difference. But at the same time, ignoring huge advancements in the language itself, tools and libraries will shy students away even further.
Yes, I agree. Also, I made a small mistake, our lab machines run the latest version of Ubuntu, but the system install of OCaml is still 4.02.3.
Yes, I could probably convince the admins to make that change. It’s not an insurmountable problem. I just wanted to add this consideration to the list and I wondered what other people thought. (I also know that maintaining many versions of software is time-consuming, thankless, and error prone!)
We’re switching to teaching in OCaml for our first year Foundations of Computer Science course in Cambridge, and I am putting together an OCaml/Jupyter Hub environment for our students. This setup means that there is no client-side software required by the students to start with, and then they can subsequently (after a few weeks of the basics) get a local environment running if the notebook environment isn’t powerful enough. Mostly though, we avoid any dependency on package management for student teaching and provide an explicit repository with all the build/exercise instructions.
I’ll share details of our Jupyter setup in a separate thread in a month or so once the quirks are ironed out. @jonludlam and I would like to get it to be a jsoo-based purely-client-side experience, but that may be out of scope for this year’s teaching. This used to with with iocamljs, but the Jupyter codebase has diverged quite a bit since @evilkidder wrote iocamljs sadly!
@avsm Have you considered using learn-ocaml? The Paris 7 OCaml course switched to it this year (I was TAing), and AFAICT it provides most of the jsoo-based purely-client-side experience you mentioned.
Additionally, having more teaching material written for the platform would be really nice for teaching OCaml even outside of this course.
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.