The more important driver for a transition, AIUI, is that the build environments for the older tags are based on versions of CentOS that are either past (ml1) or nearing (ml2010) their end-of-life date.
At some point in this very long thread it was suggested that the new build environments should tag wheels with the older tags when they don’t need any newer library features (it should be possible to detect this automatically). I don’t know if that actually got implemented. Assuming it did, though. that would indeed be a reason why my suggested definition of “complete” wouldn’t work. Let me try again:
I claim we won’t have enough information to judge whether the perennial proposal makes sense until both of the following are true:
- A supermajority of the daily connections to production PyPI, by
piprunning on Linux, were a version ofpipthat understands themanylinux2014tag - A supermajority of the wheels on production PyPI that contain compiled code for Linux have had an upload, with a “final release” version number, that was compiled in the manylinux2014 build environment
Once those are both true, we will need to canvass the community of people who have built wheels in the manylinux2014 build environment, and the community of people who have downloaded wheels for use on Linux, to find out whether there were any unexpected problems arising from the transition that need addressing by changes to the perennial process. (Probably we’ll hear about some problems in the form of bug reports on pip, auditwheel, the build environment, and specific compiled-code packages, but I don’t think we’ll discover all of the problems if we don’t do some outreach.)