ocaml
Dune gives the wrong version when installed from source
Reported by @voodoos
After running
opam pin dune --dev-repo... when I print the version of Dune it says:3.12.0-2842-g6b7bdfeThis messes up with vscode detection of pkg features that relies on the version number being >= to 3.20
@voodoos also identified the source of the problem, which is that installing from source in this way, dune uses git describe at https://github.com/ocaml/dune/blob/main/boot/duneboot.ml#L1240-L1241
and since the current release process is not tagging main, this produces a misleading version.
It would be better that we do not include a version string at all, if we cannot print something accurate. However, moving the release process to use trunk based development should help alleviate a chunk of this pain.
An alternative is that we record the current version number in a file in the repo, and increment it as part of the release process. This is not an uncommon practice and I've had it work well in the past.
Advertising as 3.12 is indeed pretty poor, especially as the Dune binary knows that it is 3.21 (e.g. it will tell you that it supports dune-lang versions 3.0 - 3.21 if you specify an invalid version in dune-lang)
Another option could be to read the current version from https://github.com/ocaml/dune/blob/6b7bdfef836ca55d522fe1526f8930814c0e0431/otherlibs/dune-rpc/private/types.ml#L30 and append something like the current datestamp. e.g. 3.21~pre20251127 (so the Debian convention where ~ lowers the value in version sorting).
This has the advantage that the version info is usually updated fairly early in the release process as it is required for version gating in new dune-lang stanzas.
We use git describe to find the version so one way might be to tag 3.XX+alpha on main itself, that way git describe can find it.
We use
git describeto find the version so one way might be to tag3.XX+alphaonmainitself, that waygit describecan find it.
Sounds like a nice fix to me. We can just start tagging the point before release branching with the current release model, and this will also fit if we can move to trunk based dev.
On some reflection, what I propose is that after each release branch is cut for version l.m.n, we tag main with a snapshot ``l.m.n+1-snapshot`.
On some reflection, what I propose is that after each release branch is cut for version l.m.n, we tag main with a snapshot ``l.m.n+1-snapshot`.
I think that would mean the snapshot tag could contain features that weren't released in l.m.0. Not the end of the world, but is also bound to be confusing to some people.
I think that would mean the snapshot tag could contain features that weren't released in l.m.0. Not the end of the world, but is also bound to be confusing to some people.
That's the point of the snapshot.
I think we should be able to move to a release flow where we generally release from trunk, and only need to branch if we need to back fix patch versions. In the meantime, we can adopt the practice of merging the release branch back into the main, which @rgrinberg has preferred over a snapshot tag.