Pillow 8.3.2 release breaks semantic versioning by using manylinux2014 instead of manylinux2010 wheels

[jbarlow83]

Pillow 8.3.1 provides manylinux2010 wheels, but Pillow 8.3.2 changed to using manylinux2014.

I respectfully submit that changing the supported manylinux version is a breaking change under semantic versioning, since it breaks compatibility and ends support for any downstream users of Pillow that target manylinux2010, and forces them to change to manylinux2014 wheels as well. It also ends support for any users whose Linux distribution is not manylinux2014-compatible.

To illustrate the problem, suppose a build script for a package that requires "Pillow >8, < 9" runs on the manylinux2010 build image. It will use pip, attempt to download the latest Pillow, and fallback to a source build because there is no manylinux2010 wheel. Since the source build has many dependencies, it will likely fail as well unless all dependencies of Pillow are available.

I believe the options would be to:

1. Build and add manylinux2010 wheels to Pillow 8.3.2 on PyPI, or,
2. Re-release Pillow 8.3.2 as Pillow 9.0.0

[hugovk]

Pillow 8.3.1 provides manylinux2010 wheels, but Pillow 8.3.2 changed to using manylinux2014.

Slight correction: CPython manylinux1 and PyPy manylinux2010 have been changed to manylinux2014.

[radarhere]

Here are PyPy manylinux2010 wheels I've just put together for Pillow 8.3.2 - Pillow-8.3.2-pypy-manylinux2010.zip

[radarhere]

And here are the CPython manylinux1 wheels for Python 3.6 - 3.9 - Pillow-8.3.2-CPython-manylinux1.zip

[radarhere]

@hugovk shall I upload all of those wheels to Pillow 8.3.2 on PyPy?

[hugovk]

Yeah, that's probably the easiest this time.

[hugovk]

Although I'm not sure this is a semantic versioning break, I don't fully understand the original use case.

Pillow doesn't support EOL versions of Linux, although it may well still work on them. We use semantic versioning for CPython support but not Linux support:

Binary distributions are contributed for each release on a volunteer basis, but the source should compile and run everywhere platform support is listed.

Pillow requires a modern version of pip (and upgrading pip before Pillow is recommended in the installation docs), and I understand pip >= 19.3 supports manylinux2014.

pip 19.3 was released Oct 14, 2019, I think it's fair enough to need a less than 2-year-old pip to install a 2-day-old Pillow. Python 3.6 comes with an older pip 18, it's easy enough to upgrade.

Another option is using pip's --only-binary :all:, which will use the newest binary available and skip source installations.

"Manylinux1 is obsolete, manylinux2010 is almost EOL, what is next?" concludes:

• Use pip v20 or later to make it easier on library packagers: modern pip versions will take the latest manylinux package they can support and will be forward-compatible with the PEP 600 perennial manylinux standard.
• Manylinux1 and Python 3.6 are going away. Update your systems.

And Pillow will drop support for Python 3.6 when it reaches EOL in December, the January release will be Pillow 9.0.0.

[radarhere]

Ok, the wheels I posted earlier have now all been uploaded to PyPI.

[jbarlow83]

@radarhere Thanks for uploading those wheels.

@hugovk
The version of pip is not at issue here. There are systems that can run Python 3.9, pip 21, but are still only manylinux2010 compatible - one such system is the manylinux2010 Docker image itself. Using --only-binary :all: would fail on an attempt to install PIllow 8.3.2 (prior to uploads), but pass on an attempt to install 8.3.1.

If you define your use of semantic versioning as only applicable to CPython and not binary distributions, then you can say you did not break your policy.

However, I think it's fair to say that if you make a change in how you distribute binaries or the platforms supported by your binaries, you did break backward compatibility in the way that matters to users and developers, because things that used to work stopped working. Semantic versioning is, or ought to be, promising that it is safe to upgrade from 8.3.1 to 8.3.2 and nothing will stop working. Equivalently, semver lets other package maintainers write "Pillow >=8, <9" and be confident that they will support 8, and when 9 is released they will be able to review their code and make appropriate adjustments.

I absolutely agree with dropping manylinux1, manylinux2010, Python 3.6, etc. when they reach EOL and intend to do with my own projects - but it will be a major release.

[hugovk]

Thanks for the reply!

one such system is the manylinux2010 Docker image itself

This uses CentOS 6, EOL since 2020-12-31.

https://github.com/pypa/manylinux#manylinux2010-centos-6-based---eol

Arguably the CentOS 6 removal was in Pillow 8.1.0, possibly warranting a major bump.

Let's check the other removals since 8.0.0: we also removed Fedora 31 and 32, and Amazon Linux 1. Three of these happened to fall under the same quarterly release (8.1.0), the fourth in another (8.3.0): should these have been major bumps?

Alternatively, to coincide with Python 3.6 removal in Jan 2021, should we keep testing them for up to an extra 15 months after EOL? (Fedora 31 removed in Oct 2020 -> Jan 2021)

Similarly, what about other dependencies? Do we need to test/support old pip versions, olefile, FreeType, harfbuzz, FriBiDi, libwebp, etc? And Python patch versions such as Python 3.8.4, 3.8.5, 3.9.6, 3.9.7?

Our test matrix is already pretty big: ~ 20 Linux + 7 macOS + 16 Windows + 3 for fuzzing, valgrind, linting.

But I get your point about "things that used to work stopped working", and this wasn't an intentional change. (With SemVer you never know what bug will break things for you; one of the arguments for CalVer is SemVer doesn't deliver on its promises https://speakerdeck.com/hynek/on-the-meaning-of-version-numbers.)

Anyway, thanks for the report and happy it was an easy enough fix this time!

---

More concretely, maybe we should also upload old manylinux wheels for the October 8.4.0 release, at least manylinux1 for Python 3.6, as that's the only one that appears to be a problem?

And then for the January 9.0.0 release (post 3.6 EOL): drop manylinux1 and manylinux2010, and only use manylinux2014+?

[jbarlow83]

The manylinux2010 image uses CentOS6 which uses EOL, but manylinux2010 is just a specification and that specification is not deprecated. I believe manylinux2014 can be instructed to create manylinux2010 binaries.

It's quite possible that some of these changes warrant major releases. If you bump the required version of a dependency that usually should be a breaking change.

Some choose to interpret SemVer by making almost all releases breaking, except for perhaps x.0.1 hotfix - at least downstream packages are forewarned.

It is true that SemVer doesn't deliver on its promises, but it is far better than CalVer for release engineering, for libraries anyway.

[jbarlow83]

I'll close this now that the 2010 wheels are up on PyPI. Thx.