On 10 February 2018 at 16:03, Mark Williams <m...@twistedmatrix.com> wrote: > On Tue, Feb 06, 2018 at 05:55:36PM +1000, Nick Coghlan wrote: >> By contrast, year-based CalVer maintains distro-neutrality, while also >> giving a good sense of the maximum age of compatible target platforms. >> (e.g. given "manylinux2010", it's a pretty safe guess that Ubuntu >> 12.04, 14.04 and 16.04 are all expected to be compatible, while that >> isn't as clear given "manylinux2" or "manylinux6") > > I'm convinced we should use CalVer. > > I'm still skeptical of the utility of CalVer here. Debian 6.0 > (squeeze), for example, was released in 2011 but is incompatible with > `manylinux2010` wheels because it uses glibc 2.11. I'm concerned that > the sooner `manylinux2015` is defined, the more likely it is to > describe too fuzzy an ABI era for CalVer to convey meaningful > information to the LTS audience.
Yeah, I'd agree with that - there's a fuzzy multi-year period from when libraries are available to when they become ubiquitous, so given a "manylinux2010", it would be surprising if a 2012 release like Ubuntu 12.04 didn't support it, but for distros released in 2010 or 2011 you'd still need to check the details. And even after that adoption period, there are always going to be distros that make other choices (like Alpine deciding glibc was too large). > What makes it worth it is the ability to skip and backfill versions. > As you you pointed out, it would be a strange version scheme that had > an architecture that gained wide support in 2015 become `manylinux3` > and one that gained wide support in 2014 `manylinux4`. > > In particular, Geoffrey Thomas pointed out that it should be possible > to produce nearly-`manylinux1` compliant wheels with a much newer > toolchain: > > https://mail.python.org/pipermail/wheel-builders/2017-July/000283.html > > We may decide that an update to `manylinux1` is worthwhile, and by > switching to CalVer, backfilling that version as `manylinux2008` would > be straight forward. Indeed, that concrete pragmatic benefit provides a more compelling rationale for switching the numbering scheme. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig