`devX` tags get special treatment

[sajith]

I'm not sure if this is a bug or feature, but it does not seem to be documented.

I have been using devX tags in a couple of projects that happen to use setuptools_scm, and it's been working just fine so far. Lately they've just started emitting these errors when pip install-ing them:

ValueError: choosing custom numbers for the `.devX` distance is not supported.
 The 2.0.6.dev1 can't be bumped
Please drop the tag or create a new supported one ending in .dev0

That caused some head-scratching. Why devX tags get this treatment, and why not, say, rcX tags? I'm sure there are good reasons, but it would be nice to have this behavior documented.

[RonnyPfannschmidt]

It's the most safe/sane component of the version as by the python pep for package versions to put under control

Any deliberate release ought to come from a tag

[sajith]

I'm sorry, I'm afraid that I do not understand that reasoning. :-)

By python pep, you mean https://peps.python.org/pep-0440/? That PEP only seem to document certain usage patterns of .devN tags, which is what I thought I was doing when creating .devN tags. Shouldn't setuptools_scm users be free to use whatever .devN tag they want to use? If setuptools_scm would like to make that decision and reserve .devN tags for itself, could that be documented?

Speaking for myself, the whole point of choosing setuptools_scm was the ability to make more ad-hoc versions with less deliberation between releases. Perhaps I misunderstood...

[RonnyPfannschmidt]

Setuptools-scm is more about using the scm as the source of truth

The default version shemes use .dev to create pseudo unique versions per commit

Most quick/ad hoc releases would then simply get a non dev version tgged

[sajith]

Wouldn't git commit hash be enough to create pseudo unique versions? The previous behavior was creating packages with names like <package-name>-<tag>-<shorthash>, regardless of tag name, and it worked just fine for me, until it turned out that .devN tags are out of bounds. It broke a couple of packages for me. I will have to go around and remove a bunch of old .devN tags from a couple of repositories.

I sincerely appreciate the work done on setuptools_scm, but I also want to register a little protest here: it does not seem right for build tools to get in the way, or break existing builds, or spring surprises like this. If it must be done, it should be documented.

Perhaps I should have pinned setuptools_scm, or perhaps I should not rely on it anymore. :-/

[jziolkowski]

Please help me understand something, maybe I don't get how this tool does its thing.

I have develop and master branches. Master is used only for "big" releases, f.e. to PyPI. The last commit pushed to master has a manually added tag, so I can control when semver changes happen. This one is clear.

But I also want to have github prereleases for every PR merged to develop. Last time I setup this tool it was correctly bumping the .devX tags with the expected distance from the last non-dev tag. But recently it shows the same error as above.

So how should I configure that tool so it allows me to achieve that I want?

[jziolkowski]

or to put it differently: when the tool sees the latest tag is x.y.z.devX, why it doesn't drop the .devX part and re-calculate the distance from x.y.z again, to make a new devY?

[RonnyPfannschmidt]

The tool refuses to hide incorrect usage and incorrect data

If a specific dev version is tagged,then guessing is no longer safe

A non numbered dev tag can be used to denote the start of a new line

A explicit dev tag means we no longer know the intent and refuse to guess

[jziolkowski]

So it means that there can be only one .devX tag after a "full" tag, yes? F.e. if I already have 1.2.3.dev12, I then need to manually add 1.2.3 in develop, so it's then versioned with .dev0?

I'm confused with the logic behind it or the what is the use case.

Under what circumstances after I have a release 1.2.3 I could then get multiple 1.2.4.devX pre-releases?

[RonnyPfannschmidt]

Every commit after the tag gets a own version, x being the distance from the Tag

[jziolkowski]

That's what I thought. But when it tries to tag the next commit after an already present prior .devX, it throws the error.

[RonnyPfannschmidt]

The dev version ought not to be tagged

[RonnyPfannschmidt]

The dev version is implied by the latest tag and the distance

A dev tag to denote the start of a new base version explicitly ought not to have a distance

[jziolkowski]

ok then, we're getting somewhere. So if I want to have prereleases in GH, I should simply tag them with anything that does not match the tool pattern, so it does not bump version from something it should not.

Correct?

[RonnyPfannschmidt]

What kinda pre release do you want

Pep440 has a lot of painful Nuance

[jziolkowski]

I want each commit to develop to be a GH prerelease (I need built binaries from CI). I don't care about how its tag is defined, as long as it doesn't break the flow of this tool.