package verison doesn't equal to tag version

[archeno]

my latest tag is v1.1.0 , however, after build, the generated package verison is v1.1.1, why?

[archeno]

here is my toml configurations:

[build-system] requires = ["hatchling","hatch-vcs"]

[tool.hatch.version] source = "vcs"

[RonnyPfannschmidt]

More details needed

A commit after the tag is supposed to have a dev version with a bit more on it

[BrianJKoopman]

I'm working on migrating a package from using setuptools with versioneer to using hatchling with hatch-vcs and I am seeing the same thing -- I assumed I was doing something wrong.

My latest tag is v0.11.2, but after 6 commits a build produces:

$ hatch version
0.11.3.dev6+ga09f7b9

I would have expected 0.11.2.dev6+ga09f7b9. What additional details would be useful?

Tag list for completeness:

$ git tag
v0.1.0
v0.10.0
v0.10.1
v0.10.2
v0.10.3
v0.10.4
v0.11.0
v0.11.1
v0.11.2
v0.2.0
v0.3.0
v0.3.1
v0.4.0
v0.4.1
v0.4.2
v0.4.3
v0.5.0
v0.6.0
v0.7.0
v0.7.1
v0.8.0
v0.8.0.dev1
v0.8.0.dev2
v0.8.0.dev3
v0.8.0.dev4
v0.8.0.dev5
v0.9.0
v0.9.1
v0.9.2
v0.9.3

EDIT: Added the fact that I'm migrating from using versioneer, which is where my expectations got ingrained. The behavior of versioneer is similar to output from git describe --tags --dirty --always, which is what makes sense to me.

[BrianJKoopman]

Ah, so after some digging I found that this seems to be the default behavior of setuptools-scm, as documented here. It'll automatically add one "to the last numeric component of the tag."

The closest thing I can find to get the behavior I expected is the no-guess-dev implementation of setuptools_scm.version_scheme. This can be passed to hatch-vcs with:

[tool.hatch.version.raw-options]
version_scheme = "no-guess-dev"

That'll produce a tag like: 0.11.2.post1.dev7+ga1e7e91.d20240831

[RonnyPfannschmidt]

It's important to note that .dev sorts as lower than non dev versions, so not incrementing something would be utterly wrong

[BrianJKoopman]

It's important to note that .dev sorts as lower than non dev versions, so not incrementing something would be utterly wrong

Doesn't .post1 here make it sort higher than the non-dev 0.11.2 though? The sorting example in PEP440 shows:

1.dev0
1.0.dev456
...
1.0
...
1.0+5
1.0.post456.dev34
1.0.post456
1.0.15
1.1.dev1

I'm not really looking to actually release based on these intermediate versions, just know where I am relative to the latest release. Really I want a scheme that adds just a local version identifier with the number of commits and a hash past the latest tag, for instance: 0.11.2+7.ga1e7e91

What threw me off especially is the example in the "Migration tips" section of the hatch-vcs docs, which shows:

$ hatch version
23.0.0.dev17+g462372ba

Under the default version scheme I don't understand how this version is possible. If the latest tag was 23.0.0 shouldn't hatch-vcs produce a version of 23.0.1.dev17+g462372ba? Incrementing the patch version by 1.

[RonnyPfannschmidt]

indeed it should