Version management of highly developed package on OPAM

I’m maintaining an OPAM external repository for our package, say package A. The package A requires package B as dependency. We use a fork version of B version 0.1, named version “0.1+a”. The package B 0.1+a is distributed by our own OPAM repository.

A 1.0 <-- B 0.1+a

The forked version of B is highly developed. But its version string can’t be changed from “0.1+a” because it’s still a fork of the original B 0.1.

This causes a problem when rebuilding A after an update of the forked version of B. It needs a manual update of B because OPAM doesn’t understand the update.

opam reinstall b

So my question is: how to manage updates of our forked packages with OPAM? Is there any standard ways to deal with this problem?

If I understood correctly you would like an automatic way to rebuild A and B. Unless you are pinning the packags, to have an auto update, you should internally release new versions, like 0.1+b and then 0.1+c and so on, and at that point running opam update and then opam upgrade would build and reinstall the right packages. Note also that the opam package of B needs to expkicitly list its dependency on A.

@mseri Thanks for your reply. I mean “forked version of 0.1 for package A” by “0.1+a”, so I will use “0.1+a.1”, “0.1+a.2”, or something if I use your method. Or, it’ll be also OK to use vgo’s format such as “0.1+a.yyyymmddhhmmss.commit”.

Is this format OPAM-ish? I haven’t seen such complex version strings…

See here for opam’s version definition and order.

See @dbuenzli reply. But if you use them internally then you can pick either of them, I think they should be fine as long as they are incremental with respect to the opam definition of incremental

Thank you @mseri @dbuenzli. I’ll try that :slight_smile: