Re: [Caml-list] Tools for helping backward compatibility?

["François Bobot" <francois.bobot@cea.fr>]

Le 22/08/2020 à 06:09, Yawar Amin a écrit :
> Do you mean something like Semantic Versioning here? See e.g. Elm which has a package manager that
> can enforce SemVer by comparing types: https://elm-lang.org/news/0.14


Thank you a lot for the pointer. Unfortunately I'm yet not able to find details about the tool (dead
links). Still:

$ elm diff Microsoft/elm-json-tree-view 1.0.0 2.0.0
This is a MAJOR change.

---- JsonTree - MAJOR ----

    Changed:
      - parseString : String -> Result String Node
      + parseString : String -> Result Error Node

      - parseValue : Value -> Result String Node
      + parseValue : Value -> Result Error Node


I think it is better to let developers choose how/if they want to mark in the version breaking
changes. Such tooling to detect problematic changes is already difficult without adding normative
bike-shedding.

I don't have the details of their tools, but it seems that a differences would be that the API
developers would have the ability to tell which changes are problematic, and so how the user of the
API can use it.

> 
>> For package authors, it means we can automatically enforce semantic versioning. No user will ever
> get a breaking API change in a patch version again!
> 
> Something like this for OCaml would be very cool. But I've heard that SemVer for OCaml is either
> difficult or effectively impossible, indeed due to some of the reasons you listed. I think any
> practical codification of backward-compatibility rules would probably need to ignore the presence of
> features like 'module type of' and 'include'.

SemVer is difficult or even impossible in OCaml if you don't restrict what the user of the API can
do with it. For any API change you can create a program that will be broken by it.

There is one case where you can use `module type of` and `include` without any backward
compatibility problem (except removing the library). Reexporting a library:

module A : module type of Lib = struct include Lib end

So if you don't have any guarantees, the only accepted use of `module type of Lib`, could be this
one. With more guarantees, other usual uses of `include Lib` can be accepted. For `module type of`
it is more contrived, like guaranteeing to not add new types and values.

But it is not a bad thing to forbid that for external libraries. For internal use those constructs
can always be used since all the modules of one library move in lock-step. Even libraries that are
guaranteed to move in lock step can avoid those restrictions between them.

Best,

-- 
François