Skip to content

Commit

Permalink
Line editing interface.mld (#1182)
Browse files Browse the repository at this point in the history
* mostly formatting

* fix typo

Co-authored-by: panglesd <[email protected]>

* changed correct to correctly for accuracy

---------

Co-authored-by: panglesd <[email protected]>
  • Loading branch information
christinerose and panglesd authored Aug 1, 2024
1 parent 468ab02 commit 160931f
Showing 1 changed file with 12 additions and 12 deletions.
24 changes: 12 additions & 12 deletions doc/interface.mld
Original file line number Diff line number Diff line change
@@ -1,40 +1,40 @@
{0 [odoc] interface guarantees}
{0 [odoc] Interface Guarantees}

[odoc] has several 'public facing' parts with varying levels of support guarantees.
This document describes what those interfaces are, what the support levels are
now, and what we aim for in the future.

{2 Documentation Comments}

The first and most important is the syntax of the documentation comments present in source code.
The first and most important is the syntax of the documentation comments present in the source code.
This 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.
We have a separate page describing the {{!page-ocamldoc_differences}markup differences from OCamldoc}.

{2 CLI Interface}

The way in which the [odoc] CLI is invoked is not trivial, and it requires careful
ordering and correct arguments to produce correctly linked documentation. It’s not expected that
end-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
each release of [odoc], so we’ll ensure backward compatibility of the CLI as much as possible.
The way in which we invoke the [odoc] CLI is not trivial, and it requires careful
ordering and accurate arguments to produce correctly linked documentation. It’s not expected that
end 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
each [odoc] release, so we’ll ensure CLI backward compatibility as much as possible.
There are currently three ‘first class’ tools that 'drive' [odoc]. We will not make
releases of [odoc] whilst knowingly breaking these tools. These are:

- Odig
- Dune
- OCaml

Here, OCaml refers to the newly merged configure option (from 4.12.0) that builds the standard library documentation with
[odoc]. If the recommended way of invoking [odoc] changes, we will work with the maintainers of these projects
to ensure they are updated correspondingly.
Here, OCaml refers to the newly-merged configure option (from 4.12.0) that builds the standard library documentation with
[odoc]. If the recommended way of invoking [odoc] changes, we will work with these projects' maintainers
to ensure they are updated accordingly.

Additionally, there will be a reference implementation of a tool to build [odoc]'s documentation, which should
serve as a guide for anyone building other 'drivers' of [odoc].

{2 Output Formats}

[odoc] currently outputs HTML files, man pages, and LaTex documents. In a similar vein to the CLI interface,
we will try to ensure that the three tools described above will not be broken by any changes to the
outputs. That is, they will succeed and produce ‘correct’ documentation. Although, we don’t make any
we will try to ensure that any changes to the outputs will not break the three tools described above.
That is, they will succeed and produce ‘correct’ documentation. However, we don’t make any
guarantees about the internal structure of the output documents; e.g., the exact nesting of
tags 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.

Expand All @@ -45,5 +45,5 @@ no guarantees about the stability of the API.

{2 Intermediate Files}

The intermediate files that [odoc] produces ([.odoc] and [.odocl]) should be considered to be internal only
The intermediate files that [odoc] produces ([.odoc] and [.odocl]) should be considered internal only
and tied to the specific version of [odoc].

0 comments on commit 160931f

Please sign in to comment.