Release Pillow 6.1.0 on July 1, 2019 #3835
Comments
|
Less than a week to release! Let's review some more contributor PRs. Is there anything still needing release notes? |
|
@hugovk @radarhere Can we start a new thing where whoever is planning to do or lead the release self-assigns themself to these release issues? We now have 4, count them 4 (if you include me) folks capable of doing a release but I've lost track of what our schedule is (if we even have one). With @wiredfool and I lurking, it's typically either @hugovk or @radarhere so let's just figure out what the plan is for say, one year in advance. E.g. every other between @hugovk and @radarhere ? All four of us so as not to overwhelm one developer? I don't have any strong preference just want to firm it up … thanks. |
|
Sure, @radarhere did the last one, I'm good to do this one. @radarhere and I have been alternating, which I think's fine, and if there's one we can't do then we can just pipe up in advance and one of the other three can do it. For example, I can't guarantee to be available every single 1st January, because I might be away on holiday and without a computer. We've been updating the release checklist as needed each release. |
|
Will start the release soon. Any last minute additions needed? To merge:
|
|
All merged in for this release. Now waiting for master to turn green on the CIs (AppVeyor is sooo sloww, last 3 were 53/63/47 mins. We need to start shifting it to AZP). |
|
(I accidentally pushed 6.2.x to the 5.2.x branch. I've reset this back to the 5.2.0 tag.) @cgohlke Please could we have Windows binaries for 6.1.0? |
|
Some new failures on pillow-wheels,
With:
https://travis-ci.org/python-pillow/pillow-wheels/builds/552752918
|
|
I suggest:
Thoughts? For 1) see #3931 to loosen the epsilon for FreeType 2.10. |
|
@hugovk How about delete the tag and just release 6.1.0? Any downside to that? |
|
That is possible, a downside is the tag is already "out there" and we don't know if anyone has done anything with it already. |
|
Could just delete it quickly now and hope for the best? |
|
@hugovk I'm comfortable taking responsibility for any damage done by updating the tag rev. I don't feel like that's as offensive as releasing different versions of 6.1.0 to PyPI (which we'd obviously never do). In other words, the requirement for a point/bug fix release should be that there is an actual release, not just that we've tagged a release. In this case, we just tagged it (right?) and we caught a bug so I think it's OK to delete and re-tag. |
|
OK, 6.1.0 tag deleted and will re-tag the new one. Thanks! |
|
The new tag is ready and pillow-wheels is green. Take 2: @cgohlke Please could we have Windows binaries for 6.1.0? |
|
I'm running into two issues:
|
Likely from #3780 (ping @nulano):
What's the full version of the failing pypy3? |
|
Segfault at Pillow/src/libImaging/Convert.c Line 1045 in 9300ced |
and |
|
How could the tests ever pass? Maybe I'm missing something, but shouldn't this be: diff --git a/src/libImaging/Convert.c b/src/libImaging/Convert.c
index 038a83fe..5df48fb2 100644
--- a/src/libImaging/Convert.c
+++ b/src/libImaging/Convert.c
@@ -1041,7 +1041,7 @@ static void
p2i(UINT8* out_, const UINT8* in, int xsize, const UINT8* palette)
{
int x;
- for (x = 0; x < xsize; x++, in += 2, out_ += 4) {
+ for (x = 0; x < xsize; x++, out_ += 4) {
INT32 v = L(&palette[in[x]*4]) / 1000;
memcpy(out_, &v, sizeof(v));
}
@@ -1060,7 +1060,7 @@ static void
p2f(UINT8* out_, const UINT8* in, int xsize, const UINT8* palette)
{
int x;
- for (x = 0; x < xsize; x++, in += 2, out_ += 4) {
+ for (x = 0; x < xsize; x++, out_ += 4) {
FLOAT32 v = L(&palette[in[x]*4]) / 1000.0F;
memcpy(out_, &v, sizeof(v));
}
|
|
The very same change I came up with, see #3932. |
Good. All tests are passing here. No segfaults. |
|
I've untagged 6.1.0. PR #3932 is merged to fix the segfault. That leaves the PyPy3 failure. I guess that's because Our tests didn't pick it up because we don't test PyPy3 on Windows; and whilst we do test PyPy3 on Travis CI, there is a "implicit declaration of function ‘PyUnicode_AsUCS4Copy’" warning we didn't notice as all the I've opened a ticket with PyPy asking if they also plan to deprecate/replace/remove And here's a PR to revert that change, in case we don't get a better solution in the short term: #3933. I'll need to continue tomorrow unless someone in another timezone would like to pick up the reins. Thanks everyone for the help so far! |
|
@hugovk Probably fine to wait until tomorrow, thanks for all the hard work! Much appreciated. |
|
From the PyPy FAQ:
I guess that means no modern PyUnicode functions. There might be a way to fix the original issue (#3777) using PyPy-specific functions, but probably not in time for this release. It should be possible to revert the change for PyPy only by adding a preprocessor if block; looking through the PyPy include files, the macro PYPY_VERSION_NUM seems like a good candidate. I can try to write that tomorrow. |
|
Thanks @nulano |
|
#3935 should fix the PyPy3 build failure introduced in 8d4bb33: This disables the fix for #3777 for PyPy3, as PyPy's cpyext module hasn't been updated to support the new PyUnicode functions yet.
The FreeType library was probably disabled due to a dynamic link error, not because it's not installed. FreeType works again with this PR: https://travis-ci.org/nulano/Pillow/jobs/553153042#L2976 |
I suspect this is actually a real failure. When I tried the test on Windows without the #3780 fix, I got the same values: I suggest reverting #3931 and changing the test's skip conditions to skip on all platforms when running Python 2. |
|
Regarding #3935, I just realized PyPy does support the new I could add this back, but I think it's best to wait for the coming Python 2 end of support. At that point I would like to simplify and improve both layout functions. What do you think @hugovk? |
|
Yeah, let's wait. It's only 6 months until Python 2 EOL (and 3 months until PRs can be merged). And the changes are in part to replace deprecated functions in CPython, which will be removed in CPython 4.0, due maybe 2021 or 2022 or who knows; no rush. |
|
#3935 merged and 6.1.0 retagged. pillow-wheels is queued up, although Travis is running slow at the moment so we'll need to be patient. Take 3! @cgohlke Please could we have Windows binaries for 6.1.0? |
Here you go. |
|
🚀Pillow 6.1.0 is released! Thanks everyone for the help. Edit: https://twitter.com/PythonPillow/status/1146339393046814721 |
Release notes needed
image.entropy()method (second revision) #3608Release checklist
masterbranch.masterbranch.src/PIL/_version.pyCHANGES.rst.make release-testin a freshly cloned repo.Windows
@cgohlkefor Windows binaries via release ticket e.g. Release 2.9.0 on July 1, 2015 #1174.@cgohlkeandtwine upload *.Mac and Linux
git clone https://github.com/python-pillow/pillow-wheels cd pillow-wheels ./update-pillow-tag.sh [[release tag]]wget -m -A 'Pillow-<VERSION>*' \ http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.comtwine upload dist/Pillow-5.2.0*.dev0to version identifier insrc/PIL/_version.pyPublicize Release
Documentation
The text was updated successfully, but these errors were encountered: