You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some additional flexibility over raw git describe would be useful when populating Build_info.version. For example, it would be useful to be able to generate package version numbers containing ~ to indicate (unreleased) versions since the last tagged release (e.g. using 1.5~10-3497327 for a commit with hash 3497327 that is 10 commits ahead of the 1.5 tag). Since ~ can't be used in git tags, there isn't a clear way to do this. I guess that the high level point is that it would be good if the core versioning functionality in dune could exercise the functionality that is in opam. The issues with ~ is one (maybe the only?) instance of that I have run into where I couldn't use what opam could do easily from dune.
The text was updated successfully, but these errors were encountered:
We discussed this in the meeting and decided that it would be a good convention to implement. However, it will only be enabled for projects where the dun lang is >= 2.8.
Desired Behavior
Some additional flexibility over raw
git describe
would be useful when populatingBuild_info.version
. For example, it would be useful to be able to generate package version numbers containing~
to indicate (unreleased) versions since the last tagged release (e.g. using1.5~10-3497327
for a commit with hash 3497327 that is 10 commits ahead of the 1.5 tag). Since~
can't be used in git tags, there isn't a clear way to do this. I guess that the high level point is that it would be good if the core versioning functionality in dune could exercise the functionality that is inopam
. The issues with~
is one (maybe the only?) instance of that I have run into where I couldn't use whatopam
could do easily fromdune
.The text was updated successfully, but these errors were encountered: