jon.recoil.org
this repo has no description
1{0 [odoc] Interface Guarantees}
2
3[odoc] has several 'public facing' parts with varying levels of support guarantees.
4This document describes what those interfaces are, what the support levels are
5now, and what we aim for in the future.
6
7{2 Documentation Comments}
8
9The first and most important is the syntax of the documentation comments present in the source code.
10This is relevant to everyone who is writing code that’s intended to be documented by [odoc], so it applies to the widest set of people.
11We have a separate page describing the {{!page-ocamldoc_differences}markup differences from OCamldoc}.
12
13{2 CLI Interface}
14
15The way in which we invoke the [odoc] CLI is not trivial, and it requires careful
16ordering and accurate arguments to produce correctly linked documentation. It’s not expected that
17end users will invoke [odoc] by hand, but rather it will be driven by separate tools. As a consequence, it’s important to preserve the tools’ ability to create good documentation with
18each [odoc] release, so we’ll ensure CLI backward compatibility as much as possible.
19There are currently three ‘first class’ tools that 'drive' [odoc]. We will not make
20releases of [odoc] whilst knowingly breaking these tools. These are:
21
22- Odig
23- Dune
24- OCaml
25
26Here, OCaml refers to the newly-merged configure option (from 4.12.0) that builds the standard library documentation with
27[odoc]. If the recommended way of invoking [odoc] changes, we will work with these projects' maintainers
28to ensure they are updated accordingly.
29
30Additionally, there will be a reference implementation of a tool to build [odoc]'s documentation, which should
31serve as a guide for anyone building other 'drivers' of [odoc].
32
33{2 Output Formats}
34
35[odoc] currently outputs HTML files, man pages, and LaTex documents. In a similar vein to the CLI interface,
36we will try to ensure that any changes to the outputs will not break the three tools described above.
37That is, they will succeed and produce ‘correct’ documentation. However, we don’t make any
38guarantees about the internal structure of the output documents; e.g., the exact nesting of
39tags or sequence of LaTex commands may not be preserved. We will attempt to ensure that the HTML anchors are preserved, implying that the filenames will also be preserved.
40
41{2 Libraries}
42
43[odoc]'s libraries are not currently intended to be used by other projects. There are
44no guarantees about the stability of the API.
45
46{2 Intermediate Files}
47
48The intermediate files that [odoc] produces ([.odoc] and [.odocl]) should be considered internal only
49and tied to the specific version of [odoc].