On 12 February 2018 at 07:34, Matthew Brett <matthew.brett@gmail.com> wrote:
On Sun, Feb 11, 2018 at 7:53 AM, Alex Walters <tritium-list@sdamon.com> wrote:
"There is a tool that can make software run on a lot of different computers, but only if you build it for an ancient computer. The tool is a little complicated - you have to learn how to get it and to use it with any success. The people who make it are considering changing the way they name it. The new naming scheme is the bare minimum year the computer running the code can be from.
I think the problem is that the whole discussion turns on whether we should care about the fact that it's more complicated than the last sentence would suggest.
It isn't really - what "manylinux2010" tells you is that distros released before that year will almost certainly *not* comply with that variant of the spec, since at least some of the relevant library versions weren't available yet. While it also conveys some fuzzier signals (such as "distros released in 2012 or later will *probably* be compatible, unless they make some unconventional library choices"), I agree with Mark's last email explaining that we shouldn't view that as the primary benefit of switching to CalVer based numbering: the primary practical benefit is the fact that CalVer based numbering will let us backfill specs for arbitrary years whenever it suits us to do so (e.g. a manylinux2008 as the oldest base platform that more recent compilers are able to target) We're also not assessing the CalVer numbering scheme in a vacuum, we're assessing it relative to: * numbering in order of definition (which would make backfilling intermediate years confusing) * numbering with arbitrary gaps (which allows backfilling up to a point, but means having to explain the gaps [1]) * numbering based on RHEL/CentOS version (which makes it difficult to ever choose a different baseline distro and still doesn't solve the backfilling problem) And from that point of view, we can see that if we assume CalVer as the recommended path forward, then we wouldn't have a compelling argument for switching away from it to any of the other plausible schemes. Cheers, Nick. [1] Ah, that would bring back memories of BASIC line numbering :) -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia