You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've seen this mentioned elsewhere and it makes sense -- Shipping a py 3.10 compatible/tagged wheel before the actual release can help with other libraries sorting their compatibility. It could reduce the support load here as well, as we wouldn't get the confusion from people attempting to compile for 3.10 in the window between it coming out and us (well, you) getting the new release out. This assumes that we can run the RC in the testing setup, and I'm not 100% clear that that's actually the case.
In the unlikely event that the 3.10 RC differs from 3.10 final in a significant manner, we can roll a point release.
Reacted by Tomáš Hrnčiar, David Auer, Honglei, Jay Allison and Hugo van Kemenade
We have an 11 day buffer between 3.10.0 final release and Pillow release, and I was going to suggest doing the Pillow release as soon as we're actually ready, before the end of that buffer.
But yes, sounds good to put out RC wheels first. We've already been testing this repo against 3.10 on GHA.
What's the easiest way for us to proceed? Do we need to make some code changes before creating wheels, and how best to trigger the wheel build process?
Perhaps a point release (8.3.2) with #5570 (or a subset)? And anything else?
#5570 is needed to get rid of the exit warning on Windows though, so 8.3.2 probably sounds like the best way to go.
If we're looking for 8.3.0 problems to fix, then I would suggest #5588, since that problem was introduced in #5514, and #5599 since that adds documentation changes missing from #5552.
Update on 3.10 for the CIs. In short: no release blockers.
GitHub Actions: had 3.10 available 12 hours after release. 🥇
AppVeyor: Python 3.10 support appveyor/ci#3741 is in their next-images-update milestone, no ETA, 36% complete. I'm not worried if we don't have this for Friday's release: it's for testing, we're already testing 3.10 on GHA, and we already released 8.3.2 for 3.10 with no issues.
Travis CI: no reaction at all from Travis to the request: https://travis-ci.community/t/add-python-3-10/12220. I'm even less worried about this, we use Docker to create those wheels (including 3.10) so it doesn't really matter what Python is on the Travis machine (and 3.10-dev is available).
AppVeyor are still in progress with their next-images-update milestone, and no response from Travis CI whatsoever (to the 3.10 ticket, or any other ticket, as far as I can see...).
Not a release blocker, moving this issue to the next milestone.
Travis CI: no reaction at all from Travis to the request: travis-ci.community/t/add-python-3-10/12220. I'm even less worried about this, we use Docker to create those wheels (including 3.10) so it doesn't really matter what Python is on the Travis machine (and 3.10-dev is available).
Let's close this issue now, it doesn't matter when we change the Travis version (but ideally before 3.9's EOL in 2025!).
Activity
wiredfool commentedon Aug 6, 2021
I've seen this mentioned elsewhere and it makes sense -- Shipping a py 3.10 compatible/tagged wheel before the actual release can help with other libraries sorting their compatibility. It could reduce the support load here as well, as we wouldn't get the confusion from people attempting to compile for 3.10 in the window between it coming out and us (well, you) getting the new release out. This assumes that we can run the RC in the testing setup, and I'm not 100% clear that that's actually the case.
In the unlikely event that the 3.10 RC differs from 3.10 final in a significant manner, we can roll a point release.
hugovk commentedon Aug 9, 2021
We have an 11 day buffer between 3.10.0 final release and Pillow release, and I was going to suggest doing the Pillow release as soon as we're actually ready, before the end of that buffer.
But yes, sounds good to put out RC wheels first. We've already been testing this repo against 3.10 on GHA.
What do we need?
Windows
https://www.lfd.uci.edu/~gohlke/pythonlibs/#pillow already has 3.10 wheels for the newest Pillow 8.3.1, so we could upload those right away (or first check/ask for a build against RC1).
macOS and Linux
Update https://github.com/python-pillow/pillow-wheels for 3.10, first we need https://github.com/matthew-brett/multibuild to add support?
multibuild depends on https://github.com/pypa/manylinux which already supports 3.10.0 RC1: pypa/manylinux#1159.
radarhere commentedon Aug 27, 2021
pillow-wheels now has 3.10.0rc1 - python-pillow/pillow-wheels#215 and python-pillow/pillow-wheels#217
hugovk commentedon Aug 27, 2021
Great, thanks for those!
What's the easiest way for us to proceed? Do we need to make some code changes before creating wheels, and how best to trigger the wheel build process?
Perhaps a point release (8.3.2) with #5570 (or a subset)? And anything else?
radarhere commentedon Aug 27, 2021
The wheels have actually already been generated. From https://github.com/python-pillow/pillow-wheels/actions/runs/1170567136 I can download the artifacts. Here are just the Python 3.10 wheels - Pillow-8.3.1-cp310-cp310.zip.
#5570 is needed to get rid of the exit warning on Windows though, so 8.3.2 probably sounds like the best way to go.
If we're looking for 8.3.0 problems to fix, then I would suggest #5588, since that problem was introduced in #5514, and #5599 since that adds documentation changes missing from #5552.
hugovk commentedon Aug 27, 2021
Yep, fine by me to include those regression fixes too.
nulano commentedon Aug 30, 2021
#5651 fixing the FriBiDi segmentation fault would probably be good to include in a point release also.
hugovk commentedon Sep 1, 2021
Yep, looks a good candidate for inclusion too, if no objections from others.
I'll put together release notes and I can make a 8.3.2 release this week.
hugovk commentedon Sep 2, 2021
🚀 Pillow 8.3.2 with Python 3.10 wheels released:
hugovk commentedon Oct 12, 2021
Update on 3.10 for the CIs. In short: no release blockers.
GitHub Actions: had 3.10 available 12 hours after release. 🥇
AppVeyor: Python 3.10 support appveyor/ci#3741 is in their next-images-update milestone, no ETA, 36% complete. I'm not worried if we don't have this for Friday's release: it's for testing, we're already testing 3.10 on GHA, and we already released 8.3.2 for 3.10 with no issues.
Travis CI: no reaction at all from Travis to the request: https://travis-ci.community/t/add-python-3-10/12220. I'm even less worried about this, we use Docker to create those wheels (including 3.10) so it doesn't really matter what Python is on the Travis machine (and
3.10-devis available).hugovk commentedon Oct 15, 2021
Update:
AppVeyor are still in progress with their next-images-update milestone, and no response from Travis CI whatsoever (to the 3.10 ticket, or any other ticket, as far as I can see...).
Not a release blocker, moving this issue to the next milestone.
hugovk commentedon Nov 3, 2021
Update:
AppVeyor now has 3.10 available: #5805.
Still no response from Travis CI whatsoever: https://travis-ci.community/t/add-python-3-10/12220.
hugovk commentedon Nov 3, 2021
Let's close this issue now, it doesn't matter when we change the Travis version (but ideally before 3.9's EOL in 2025!).
https://github.com/python-pillow/pillow-wheels/blob/706f721b23c02b0d04061c33521562e41dc0f053/.travis.yml#L12