Non-monotonic development versions with release branch scheme

[Dan Villiom Podlaski Christiansen]

I use setuptools_scm for versioning hg-git, with the release-branch-semver scheme, where I have release branches named e.g. 1.0.x and 1.1.x. When doing a stable release, I do it on the release branch and merge it into default. Unfortunately, the devN is merely calculated as the length to the most recent tag, which then makes it decrease after a minor release is merged into the main development branch.

I checked, and I can reproduce this using both Mercurial and Git sources. For example, the version determined relative to 1.1.0 is 1.2.0.dev26+g7069705 whereas after the merge, it.s 1.2.0.dev17+g5b33fad.

As best I can tell, you cannot easily customise the devN part. For release-branch-semver, I believe it should either:

1. Use some monotonically increasing value, like the date or a timestamp.
2. Somehow take the minor into account, e.g. by multiplying the distance by 100 or 1000 times the minor release number.

[Ronny Pfannschmidt]

Currently there is no sane way to calculate the combined maximum distance

Both hg and git only provide a minimal distance

Is there a practical use case for the need of those numbers or is it only a preference

I'm not aware of a consistent/safe way to implement what you ask for

[Dan Villiom Podlaski Christiansen]

Yeah, I looked at the contents of .hg_archival.txt (that's what lead me to filing #1024) and I see that's it's relatively limited what you actually have. That's why I was thinking of using the minor version since that's what's most likely to lead to the “backtracking” dev part. In this case, something like:

• 1.2.0.dev26+g7069705 would be relative to 1.1.0 whereas 1.2.0.dev1017 would be relative to 1.1.1.

Anyway, there isn't much practical use of this; I just wanted to use the GitLab package registry for installing the latest development build, and was rather surprised that it didn't work.

[Ronny Pfannschmidt]

ah, now i get the problem - and indeed - both git and hg dont allow for that easily

however i beleive another mistake is in there - we should add some type of increment for distances so that the commit doesnt hit

aka https://github.com/pypa/setuptools_scm/blob/main/src/setuptools_scm/version.py#L299 needs to trigger a bump

we need a better test there, but basically - you shouldnt be hitting 1.2.0.dev after a merge

i need to line up the examples, a bit better

[Ronny Pfannschmidt]

please outline the way you use branches, tags and merges in more detail

i suspect we need errors in the release branch semver scheme for certain cases + better handling of missed increments