Skip to content

[RFC] How to handle versions #880

@ghost

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

  1. how should Dune decide what the version of a package present in the workspace is?
  2. how should Dune decide what the version of an installed package is?
  3. how should this information be communicated to opam? in particular when pinning a package
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions