tiran
commented
2 months ago Small correction: The build number is not part of the version. The build number is only part of the wheel file name and not part of the package metadata.
build tag Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an int, and the second item being the remainder of the tag as a str.
A common use-case for build numbers is rebuilding a binary distribution due to a change in the build environment, like when using the manylinux image to build distributions using pre-release CPython versions.
Build numbers are not a part of the distribution version and thus are difficult to reference externally, especially so outside the Python ecosystem of tools and standards. A common case where a distribution would need to referenced externally is when resolving a security vulnerability.
Due to this limitation, new distributions which need to be referenced externally should not use build numbers when building the new distribution. Instead a new distribution version should be created for such cases.
The version number can include a post release number. The post release number is part of the version of a package and therefore in the package metadata. The post number is visible in "pip list".
We can use either post release number or a combination of post release number + local version track CVE fixes. We could also include a custom file in the package metadata with release notes.
shubhbapna
We need to be able to track rebuilds of packages. One way to do that is to set the build number part of the version.