github release tag convention does not match python/pip version tags (2022.12.07 GH vs 2022.12.7 pip)

[danekantner]

github release tag convention does not match python/pip version tags, the GitHub scheme being used fills in single digit date fields with a prepended 0, but the Python version scheme does not (2022.12.07 vs 2022.12.7)

This is causing many tools that assess versions to have the incorrect information. This is particularly relevant and problematic because Github has originated CVE-2022-23491 stating impacted versions using the Github release tags 2012.12.07, but the package that actually gets deployed will always report out to be version 2022.12.7 based on the python/pip version scheme.

The Github release tags should match what is reported in the actual Python/Pip package metadata that is built from the same release.

[danekantner]

The naming convention of pypi to drop the 0 from dates (in python wheel setup tools) seems to have been firmly established when this issue was closed by modifying documentation to remove the 0 instead of changing the behavior of how it works: pypa/setuptools#302

[danekantner]

This was previously discussed in #208 but closed without resolution

[sigmavirus24]

There is no resolution to be had. We have a clear and standard versioning scheme. Parts of python's packaging ecosystem normalize names in a way that's well documented and reusable as a library. If people claiming integration with Python aren't normalizing things themselves, they aren't doing a good job of integrating. If you're paying them, demand they do better because you're not getting what you paid for.

It's not imperative that we satisfy inaction on the part of companies lying about their support of this language's ecosystem.

[danekantner]

For some tools this may resolve itself shortly -- NIST has updated the CVE definition to match the version scheme used in the built artifacts/python