I have been its nominal maintainer for the last few years (see below for a more detailed description of the current status of the library), but my day job and other higher-priority projects do not leave me enough time to work on OMD. Because of this, there hasn’t been a new release of the library since late 2014.
With this in mind, I am posting this with the hope that someone interested in taking up maintainership of the library will step forward. I will be happy to help this person get up to speed, share what I know, etc.
A bit of background about the current status of the library:
This library (which among other things is used to build the website ocaml.org) had its last release in late 2014. When I took over maintainership circa 2018, I embarked on a big rewrite of the code with the following objectives:
simplify the parsing code which was so complex that it was virtually impossible to extend, modify, etc;
simplify/improve the internal AST representation which is the main interface used by library clients;
add support for some markdown extensions
The current status is as follows:
(1) and (2) are mostly done: the full commonmark test suite passes with the exception of a few edge cases.
(3) is only partially accomplished; there is still a lot of room for improvements here, but this is an implementation issue, so it doesn’t need to happen before the next release;
@nojb, Thanks. Is it possible to do some kind of 2.0.0~alpha1 release, that doesn’t promise any API stability, but still offers the command-line tool? Would this mess up users of OMD that depend on the API? Or is this a new API anyway, so no existing user would be broken that wouldn’t be broken by 2.0.0?
To add a bit of background, I used to use OMD, and eventually switched away to JS libraries because the old OMD didn’t handle some ordinary cases (I don’t remember the details). I would like to switch back (and I do still use the old OMD when it is suitable). I just need the omd binary for my purposes.
Of course, I can pin the repo for my own usage, but this is both (1) slightly annoying for me (2) not reasonable to expect of downstream users in projects that have them.
Based on this experience, my impression is that OMD is really languishing, but that could be substantially (though not completely) fixed by releasing the current code if omd works.
Yes, this is possible. I’m not sure if OPAM has any special support for such “alpha” or “unstable” releases, but at most a user who wants to stay with the last stable version will have to pin it explicitly.
I use it heavily on a couple of projects and would like to see it continue in a good state. I would be open to taking it. Having said that, if one of the already active contributors is up for it, that probably makes more sense.
I’m only able to work on OCaml projects in my free time, and this makes my availability somewhat limited and unpredictable, but I’d be happy to maintain (or co-maintain, along with @sonologico or other interested folks). Even with my limits on time, I could certainly commit to timely review of contributions, to regular releases of packages, and to helping advance the state of the code (when time permits).
I don’t think there is any special machinery, but many packages have ~alpha and ~beta releases.
If you make the release we can use the opam-ci to check if anything is broken, add the relevant upper bounds and ping the interested maintainers. I will be happy to help with the release if needed
For people who are curious about how OMD compares to the competition (in other languages) in terms of performance, I ran some benchmarks which suggests that OMD 1.x was not state-of-the-art, while OMD 2.x is: the native-compiled version is faster than fast Javascript implementations running over Node.js.