On 05.02.2018 16:51, Nick Coghlan wrote:
On 5 February 2018 at 18:03, Ivan Pozdeev via Distutils-SIG <distutils-sig@python.org> 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,
On 05.02.2018 5:15, Nick Coghlan wrote: 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". The point is, a year has negative informativity in this case.
The very reasoning "compatible with most distributions released since year <X>" is flawed 'cuz it's vague and nonintuitive. Which is "most" distributions? Which part of the year X? Does that mean <distribution X version Y> is included or not? How do I even know all that without checking the spec? (Normally, a year in an entity's name means that entity's release year.) That, provided I even remember the relevant years -- since compatibility is governed by other things, I have absolutely no reason to. A year would thus add confusion and/or encourage people to use that "easy way out" reasoning and not actually check what they're signing up for -- with the ensuing landmines to step on. -- Regards, Ivan