On 5 February 2018 at 18:03, Ivan Pozdeev via Distutils-SIG <distutils-sig@python.org> wrote:
On 05.02.2018 5:15, Nick Coghlan wrote:
The intended benefit of that is that it would allow folks to go ahead and propose newer manylinux variants that allow for ppc64le and aarch64 support as needed, without having to guess where those definitions should come in a sequential series.
IMO this will bring forth more confusion that it'll solve. Technically, the ABI is linked to kernel and library versions rather than dates. Since Linux, unlike commercial products, is not locked into a particular vendor and thus doesn't have a single product life cycle forced upon it, those vary wildly between distibutions and running installations.
We pick the library API & ABI versions based on "compatible with most distributions released since year <X>", though (that's the "many" in "manylinux"). As an illustrative example, manylinux1 was essentially manylinux2007, and it's now running into problems precisely because that baseline is more than a decade old. That's not obvious if all you know is the sequential number "1", but it makes intuitive sense once you realise the effective baseline year is back in 2007. Similarly, neither manylinux1 nor the proposed manylinux2[010] will ever support ppc64le or aarch64, because those instruction set architectures are too new relative to the API/ABI definitions. With the sequential numbering, any of that kind of reasoning based on relative dates requires looking up the PEP that defined that version, finding which version of RHEL/CentOS we used as a baseline, and then finding when the corresponding x.0 major version of RHEL was released. Or, we can just put the year directly in the version number, so that publishers can go "I'm happy to target manylinux2010, because I'm fine with users of distros that are more than 7 years old needing to compile from source". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia