On 12/04/2019 04:21 AM, Victor Stinner wrote:
IMHO we need a metric to measure the risk of an incompatible change: estimate the percentage of broken Python applications. For example, run the test suite of the PyPI top 100 projects with the incompatible change and see how many fails. That's the root of the PEP 608 -- Coordinated Python release: https://www.python.org/dev/peps/pep-0608/
The problem with 608 is that it was effectively a release blocker. If somebody has the resources to put the testing and measuring into place I think it would be valuable data -- especially if those resources could then also notify the responsible parties that a breaking change was coming, or mass-media it, or something. But Python should not be held hostage to others' unwillingness to fix/upgrade their own code base, nor their inability to fix/upgrade their dependencies -- moving to the latest Python is not a requirement, and if a company chooses to maintain aging resources to support aging software, that is their prerogative. -- ~Ethan~ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YJIO67CMNQOU2WJH7EWYZLU4G5GX6P6P/ Code of Conduct: http://python.org/psf/codeofconduct/
