-
Notifications
You must be signed in to change notification settings - Fork 469
[RFC] How to handle versions #880
Description
This ticket is to discuss how version numbers should be handled by Dune. It's still not clear to me what the best way to deal with versions is.
Problems
- how should Dune decide what the version of a package present in the workspace is?
- how should Dune decide what the version of an installed package is?
- how should this information be communicated to opam? in particular when pinning a package
- how does this interact with incremental compilation?
Current situation
For (1), Dune uses the version field specified in the <package>.opam file if any, with a fallback to some other file such as <package>.version or VERSION. It never uses the output of git describe ... except when running dune subst. Some projects such as js_of_ocaml or ocamlformat use the OCaml syntax to use the output of git describe ... in development builds. We could integrate this idea properly in Dune, however there is an issue with both (3) and (4).
For (2), Dune currently doesn't know the version of installed packages. Since it always installs the <package>.opam file as <libdir>/<package>/opam, it could simply read it from there.
For (3), the problem is described here: ocaml/opam#2932
For (4), the problem is the following: if the version changes every time we commit something, then Dune might end up rebuilding things and re-running tests on every commit.