Test oldest Python on 32-bit Windows 2019 and remove AppVeyor

[hugovk]

Closes #7910.
Replaces and closes #8437.

Changes proposed in this pull request:

• On GitHub Actions, switch the oldest Python (3.9) to test 32-bit Windows 2019
• Remove AppVeyor from the test suite.

[nulano]

I would still consider whether we want to test on Windows Server 2016, but if this simplifies the CI configs then I suppose this is fine as well.

[hugovk]

How useful is testing Windows Server 2016?

It looks like its standard support is EOL and only extended, paid support is available.

https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2016

If it was a Linux distro, we would have dropped it 2.5 years ago.

[nulano]

As I understand it, paid extended support is currently only available for Server 2008 and Server 2012: https://learn.microsoft.com/en-us/windows-server/get-started/extended-security-updates-overview

For Server 2016 and Server 2019, there appears to be 10 years of regular support: https://learn.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison

With the Long-Term Servicing Channel, a new major version of Windows Server is typically released every 2-3 years. Users are entitled to five years of mainstream support and five years of extended support.

In fact, it seems that even Windows 10 Enterprise version 1507 (which is older than Server 2016) is still in Extended Support (i.e. free security updates according to https://learn.microsoft.com/en-us/lifecycle/policies/fixed#extended-support), assuming https://endoflife.date/windows has the correct date (I couldn't find any date on Microsoft's website).

This level of support to me sounds similar to Ubuntu Maintenance & Security Support (currently Ubuntu 20.04 LTS and later) or RHEL Maintenance Support (currently RHEL 8 and later).

We dropped Ubuntu 18 when it left Maintenance & Security Support around May 2023, python-pillow/docker-images#180, and Ubuntu 20 slightly ahead of schedule because it only has Python 3.8 by default, #8183 (comment).

---

However, I'd be fine with dropping support for VS2017 (dropping

Pillow/winbuild/build_prepare.py

Line 441 in 2e7da07

msbuild = os.path.join(vspath, "MSBuild", "15.0", "Bin", "MSBuild.exe")

) and Windows 1507 (replacing this runtime linking with regular dynamic linking

Pillow/src/display.c

Lines 346 to 348 in 2e7da07

	user32 = LoadLibraryA("User32.dll");
	SetThreadDpiAwarenessContext_function = (Func_SetThreadDpiAwarenessContext
	)GetProcAddress(user32, "SetThreadDpiAwarenessContext");

) if we decide that we don't include the only-security-updates phase of standard Windows support.

[hugovk]

Thanks for clarifying the support levels.

However, I'd be fine with dropping support for VS2017 (...) and Windows 1507 (...) if we decide that we don't include the only-security-updates phase of standard Windows support.

I think this can be another discussion :)

I'm leaning towards dropping AppVeyor anyway, and relying on GitHub Actions. We don't necessarily have to test everything we support.

Any further thoughts on this PR?

[aclark4life]

I'm leaning towards dropping AppVeyor anyway, and relying on GitHub Actions. We don't necessarily have to test everything we support.

Any further thoughts on this PR?

Ideally we'd test everything we support, but not at all costs. If there's a clear path to simplifying the infrastructure and workflow and the risk is that we don't test a small portion of use cases, then I'd definitely proceed because there's a good chance we'll never hear about it.

That said, if we do receive some unexpected negative feedback about the change and smaller test matrix is there any tentative plan to address those issues somehow?

If not, I'd still probably do it! But it may be nice to spend a little time thinking about it prior to removing AppVeyor.

[hugovk]

That said, if we do receive some unexpected negative feedback about the change and smaller test matrix is there any tentative plan to address those issues somehow?

We can always re-add AppVeyor again, if really needed, and the equivalent is available on GHA. Or we can consider dropping support for old things.

[hugovk]

OK, let's merge! Thanks all!