PyPI releases' numbers ≠ github tags and releases

[frenzymadness]

Hi!

I might have kinda niche issue related to the version numbers in this project. I maintain this package in Fedora Linux and I have an automation to update it every time a new release is published.

What gives my tool a little bit of a headache is the fact that the release numbers and tags on github are different (zero-padded months and days in the calver schema) from the ones on PyPI (short month and day numbers).

While both schemas are supported according to the calver specs, Python packaging guidelines and PEP 440 state:

All integers are interpreted via the int() built in and normalize to the string form of the output.

The normalization happens here because this project uses hatchling build backend, and that uses packaging.version.Version.

There is one open issue for packaging to allow non-normalized versions to support calver fully, but it's pretty old and without any activity.

It might be good to change the specification to support all possibilities provided by calver, but in the meantime, would it make sense to switch to the short format like 2026.2.3 instead of 2026.02.03 to keep github tags/releases and content on PyPI in sync?

[henryiii]

If you use pip install nox==2026.02.03 (or uv, etc), it will still work fine. All Python tooling versioning sees these as the same, following PEP 440. If you visit https://pypi.org/project/nox/2026.02.09/, that works too. All access normalizes too.

Interestingly, names also are compared normalized, but not stored in the same way. The name Cython is stored and displayed as "Cython", but pip install cython works (and wheel names are always normalized). The problem with doing that with Version directly is that you'd probably loose a lot of performance (which we care about), since you'd no longer just store integers for the release.

Maybe it could be handle for zeros without too much of a performance impact, though, with a release_zeros field that stores the number of zeros for each component. The problem would be that you'd only want this zero-padded version in the version METADATA, and not in the wheel filename, which should remain normalized. Maybe it should not be in Version, but hatchling could avoid running it through Version just for the metadata field.

Anyway, I think tags should be zero padded, as otherwise the tags probably would not sort correctly.

(This is come up in henryiii/validate-pyproject-schema-store#8 before)

[henryiii]

(I've pinged the hatchling maintainers to see if this can be fixed, I think it can)