Леонид Сергеевич <7matr...@gmail.com> writes: > DEPRECATION: reportbug 7.5.3-deb10u1 has a non-standard version number. pip > 24.0 will enforce this behaviour change. A possible replacement is to > upgrade to a newer version of reportbug or contact the author to suggest > that they release a version with a conforming version number. Discussion > can be found at https://github.com/pypa/pip/issues/12063 > WARNING: There was an error checking the latest version of pip.
Interestingly, if I'm reding the specification correctly, 7.5.3-deb10u1 is a valid semver version (although it indicates a pre-release, incorrectly in this case). PEP 440 is more restrictive than semver in that respect, though. Unfortunately, I don't see a good PEP 440 version number for what reportbug versioning is trying to do. It's sort of a post-release, but .postN only allows a single number. I'm not sure that there's anything much better than 7.5.3.10.1, which unfortunately requires more human interpretation of the last two segments (and also isn't a valid semver, which probably doesn't matter a lot but which is unfortunate). With my day job hat on, I think this is a good change for the Python ecosystem as a whole. I maintain software that has to parse Python package version numbers to check for security updates, and dealing with non-standard version numbers is a real pain. I just wish PEP 440 were aligned with semver and that both standards were a bit richer. Debian has dealt with a lot of versioning challenges that neither standard seems to have addressed, such as multiple named versioning streams that nonetheless need to maintain a total order, although our standard is also looser than would be ideal for PyPI since we try to allow for nearly arbitrary upstream version numbers. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
