There is a trend among OCaml devs which is having really many pre-releases and not reaching a final release for a long time. In particular, dune and opam 2.0: Dune 1.0+beta1 was released on Mar 8, 2017, and currently it is 1.0+beta19.1. Opam 2 alpha was released on Jul 8, 2016, and it is now 2.0.0~rc.
As a package maintainer (of Debian, Fedora, openSUSE etc.), I find it difficult to decide which version should be packaged. Usually only the latest stable release should make into the distro archive, which should contain only stable code. However, there are many OCaml libraries moved to using the beta things, e.g. replaced its build system with dune. It means that those libraries in the distro cannot be updated until dune is packaged.
I wonder if there is any way to improve the situation, say:
Try to release stable version sooner. Individual new feature/API can be labeled as experimental within the release.
Make a big warning to the beta versions that downstream projects shouldn’t depend on it yet.
Andy, firstly thank you for your packaging efforts! They are much appreciated.
Opam has maintained a nice degree of stability – once we stabilised it around the 1.2.2 release, we nominated that as the ‘LTS’ release and are ensuring that opam2 is a well-rounded release before we tag the 2.0 release. So you should continue packaging opam 1.2.2 for now until 2.0 is released.
Jbuilder and Dune have been moving very fast, and seen extremely rapid adoption. We decided last week that it’s no longer practical to call it a beta despite the developers wanting it to remain as such, and so Jbuilder 1.0 will be around the corner before we perform the name change. One area we’re putting more efforts into is testing infrastructure for larger packages (Dune, Core, Lwt, etc) so that we’ll have more visibility into breaking changes on distros. You can already see this in the container builds for many Linux distros on the opam repository CI, so that’s going to be deployed onto other projects as well.
The reason automated testing is important is to enable your first suggestion of getting stable versions out sooner to be practical. We’re basically perpetually short of developer time to triage issues, and have many many bugs on our radars. So in summary, I think we’ll have a nice summer of stable releases to look forward to as all these efforts come online. Please don’t hesitate to raise feature requests for things that will make packaging easier for you – for example, we’ve been discussing the possibility of generating RPMs and Debs directly from Dune specs, once it has enough metadata to generate the opam files.
I’m now packaging opam 1.2.2 for openSUSE. However, there is an issue that it depends on an old version of dose3, and it seems it cannot be easily upgraded. The issue was reported, but it was solved by putting a version upper bound on the dose3 dependency. Linux repositories usually only accept packages of the most recent stable version, and do not support downgrading. Right now the openSUSE dose3 package in the devel project is at 5.0.1.
Opam 1.2.2 being an LTS, would it receive updates to make it compatible with the latest versions of its dependencies? i.e. Releasing 1.2.3 that fixes the issue would be perfect. Alternatively, just an official patch would still be good.
Sorry for the possibly-silly question, but is there a reason not to advertise opam 1.3.0 and opam 1.3.1 as possible choice for users and packagers, besides their use in opam-lib? If they break compatibility with 1.2, maybe we could consider releasing an 1.2.3 with just minor fixes? (Would someone else than @AltGr be able to take care of most of the work by preparing a complete PR against the 1.2.2 tag?)
While there are quite a few improvements in 1.3 compared to 1.2.2, that benefit to its use as library for auxiliary tools (e.g. a reorganisation of modules and sub-libraries, support for compilers as packages), the corresponding opam version has never really been tested for release, and differs significantly. It was decided at the time to focus on 2.0, as adding another version to maintain, including upgrades and such, could have made support more difficult.
The main reason is that other packages of the same repository may depends on it. Usually packages are not allowed to depend on libraries outside of the repository. For example, if I want to package flowtype for Debian, I have to build it with the ocaml, sedlex, and other libraries in the Debian repository. This is a way to maintain the distro as a whole, to make sure all packages are built in a compatible way, and to make sure runtime libraries are shared (for file size, memory usage, and security reason).
In my case, my ultimate goal is to maintain the haxe package. Its upcoming version depends on some OCaml libs that switched to using dune, so I have to package dune in order to package those libs.
