On Sat, Feb 10, 2018 at 12:09:32AM +1000, Nick Coghlan wrote:
> On 8 February 2018 at 18:01, Mark Williams <m...@twistedmatrix.com> wrote:
> > Highlights from the distutils-sig thread and pypa/manylinux PR so far:
> >
> > - Should `manylinux` use CalVer (http://calver.org) ?
> 
> Just noting a subtlety of the CalVer suggestion so folks don't need to
> dig it out of the distutils-sig threads: the proposal is to switch
> from sequential numbering to instead using the approximate release
> year of the library versions specified in the manylinux baseline
> (*not* the year when we happen to define any given manylinux variant).
> 
> So if manylinux1 had been versioned that way, it would likely have
> been either manylinux2006 (based on when glibc 2.5 was released) or
> manylinux2007 (based on when RHEL 5 was released).
> 
> For PEP 571, the primary marker version is glibc 2.12, and the
> reference distro is RHEL(/CentOS 6, giving a proposed variant name of
> manylinux2010 (since both glibc 2.12 and RHEL 6.0 were released that
> year).
> 
> We don't expect this to make much difference for end users (since this
> should all be a hidden implementation detail of their package
> installer no matter what versioning scheme we use), but for publishers
> and tool developers, including the year gives a quick and convenient
> reminder of the general vintage of each target baseline.

Duplicating my response to the CalVer part of the distutils-sig thread
here:

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.

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.

-- 
  Mark Williams
  m...@twistedmatrix.com
_______________________________________________
Wheel-builders mailing list
Wheel-builders@python.org
https://mail.python.org/mailman/listinfo/wheel-builders

Reply via email to