On 7 February 2018 at 15:21, Alex Walters <tritium-l...@sdamon.com> wrote: > This is a really good point. Since pip is the main interface to packages > for end users anyways, we can call it manylinux8675309 and it wouldn't > really matter to users - the name only really matters to package > maintainers, not users. And because of that, manylinux2010, manylinux2014, > etc makes more sense. A package maintainer is expected to be more educated > about these matters, and that naming scheme is more useful to them. "Whats > the oldest linux system my code will run on?" is a very likely question a > maintainer would have when building binary packages, and the year-based > naming scheme is the logical answer.
Exactly :) Knowing the baseline year gives publishers a clear set of "almost certainly won't work" environments: anything released prior to the baseline year (since the library versions included in the baseline either won't have existed yet, or may not have been broadly adopted). This is mostly likely to become important if we end up defining a newer platform variant for the sake of ppc64le and aarch64: targeting a compatibility baseline like "manylinux2017" would make it clear that it excludes things like Ubuntu 16.04 and RHEL/CentOS 7.0 (even if it ends up including a later RHEL/CentOS 7.x point release, or the mid-LTS opt-in platform upgrades that Canonical publishes) in a way that manylinuxN doesn't. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
