Breaking compatibility and opam

Ecosystem
1

Suppose I make a major update of an opam package which breaks compatibility to previous versions. If many packages depends on my package, we need to add { < X.X.X } to a lot of packages.

I guess this is a common problem among packaging systems. I suppose this kind of situation is currently solved by manual effort, but it’s much better if this can be solved automatically somehow.

I can think of several solutions

  • Don’t do this. Keep it backward-compatible
  • If do this, change the package name
  • Introduce a convention; if the version number goes from 1.0 to 2.0, this indicates there is an incompatible change

or ?

1 Like
2

For one proposal on such things, see semantic versioning: https://semver.org/.

3 Likes
3

I know, but we need consensus to use semantic versioning.

4

Isn’t semver pretty much the standard nowadays? Do you have an example package which violates that?

5

No, but it must be implemented as an official policy of opam.

1 Like
6

Ooh, that indeed is an interesting idea. elm-package handles it well afaik and something like that for opam would definitely be nice.

1 Like
7

Ideally, build compatibility of dependent packages should be done by automated testing on PRs to the opam-repo. Changing the semantics of an existing function is not nice and IMHO should go through an intermediate package where the function is declared deprecated (or maybe one could define a new attribute for this case?) in order to ease upgrading the code.

1 Like
8

Changing the semantics of an existing function is not nice and IMHO should go through an intermediate package where the function is declared

Ideally, yes. But in practice we sometimes need to change semantics. Changing a function name may not be an option, because it clutters API.

9

Sure. So I suggest writing some documentation saying that and submitting it in a pull request to the opam repository.

1 Like