Non-monotonic development versions with release branch scheme

[danchr]

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.

[RonnyPfannschmidt]

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

[danchr]

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.

[RonnyPfannschmidt]

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

[RonnyPfannschmidt]

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

[yakaviuk]

Hi, we also have similar issue: in master branch in GitLab we create a tag, and pipeline in master branch is run once tag is created. Usually it works fine, but sometimes (we can't find specific circumstates) package name has incorrect tag (in the name). E.g. if all is fine: We created tag "1.0.28" in GitLab UI, and in "build" stage run "python -m build", as a result got artifact with name: app_name-1.0.28.tar.gz and app_name-1.0.28-py3-none-any.whl

But sometimes it works like that: tag "1.0.29" is created in GitLab UI, according to git describe tag exists:

$ git describe --always 1.0.29 $ git describe --tags 1.0.29

But "python -m build" creates artifacts with incorrect names: Successfully built app_name-1.0.30.dev0+g61e35b4e.d20240902.tar.gz and app_name-1.0.30.dev0+g61e35b4e.d20240902-py3-none-any.whl

(Instead of "1.0.29" there is "1.0.30.dev0+g61e35b4e.d20240902" in package name).

Looks like it doesn't depend on versions (newer version of setuptools-scm and Gitlab versions 16.4 and higher).

[RonnyPfannschmidt]

That is a different issue when the workdir state is dirty

Please cross-check whether you change a committed file in the build process

[yakaviuk]

That is a different issue when the workdir state is dirty

Please cross-check whether you change a committed file in the build process

I though it is some bug on setuptools-scm or GitLab side, but it was because of dirty workdir (because of git lfs). Thanks for pointing!