Skip to content

Release Pillow 6.1.0 on July 1, 2019 #3835

Description

@radarhere

Release notes needed

Release checklist

  • Open a release ticket e.g. Release Pillow 5.2.0 on July 1, 2018 #3154
  • Develop and prepare release in master branch.
  • Check Travis CI and AppVeyor CI to confirm passing tests in master branch.
  • Check that all of the wheel builds Pillow Wheel Builder pass the tests in Travis CI.
  • In compliance with PEP 440, update version identifier in src/PIL/_version.py
  • Update CHANGES.rst.
  • Run pre-release check via make release-test in a freshly cloned repo.
  • Create branch and tag for release e.g.:
    git branch 5.2.x
    git tag 5.2.0
    git push --all
    git push --tags
  • Create source distributions e.g.:
    make sdist
  • Create binary distributions

Windows

Mac and Linux

  • Use the Pillow Wheel Builder:
    git clone https://github.com/python-pillow/pillow-wheels
    cd pillow-wheels
    ./update-pillow-tag.sh [[release tag]]
  • Download distributions from the Pillow Wheel Builder container.
    wget -m -A 'Pillow-<VERSION>*' \
    http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com

  • Upload all binaries and source distributions e.g. twine upload dist/Pillow-5.2.0*
  • Create a new release on GitHub
  • In compliance with PEP 440, increment and append .dev0 to version identifier in src/PIL/_version.py

Publicize Release

Documentation

Activity

  1. added this to the 6.1.0 milestone on May 8, 2019
  2. pinned this issue on May 8, 2019
  3. hugovk commented on Jun 25, 2019

    @hugovk
    Member

    Less than a week to release!

    Let's review some more contributor PRs.

    Is there anything still needing release notes?

  4. aclark4life commented on Jun 26, 2019

    @aclark4life
    Member

    @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.

  5. self-assigned this
    on Jun 26, 2019
  6. hugovk commented on Jun 26, 2019

    @hugovk
    Member

    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.

  7. hugovk commented on Jul 1, 2019

    @hugovk
    Member
  8. hugovk commented on Jul 1, 2019

    @hugovk
    Member

    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).

  9. hugovk commented on Jul 1, 2019

    @hugovk
    Member

    (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?

  10. hugovk commented on Jul 1, 2019

    @hugovk
    Member

    Some new failures on pillow-wheels, TestImageFont.test_unicode_extended failed:

    • Mac MB_PYTHON_VERSION=2.7
    • Linux MB_PYTHON_VERSION=2.7 UNICODE_WIDTH=16
    • Linux MB_PYTHON_VERSION=2.7 PLAT=i686 UNICODE_WIDTH=16

    With:

    • AssertionError: average pixel value difference 14.7190 > epsilon 6.2000
    • AssertionError: average pixel value difference 14.7190 > epsilon 6.2000
    • AssertionError: average pixel value difference 14.7280 > epsilon 6.2000

    https://travis-ci.org/python-pillow/pillow-wheels/builds/552752918

    image

  11. hugovk commented on Jul 1, 2019

    @hugovk
    Member

    I suggest:

    1. we fix the pillow-wheels build
    2. because the 6.1.0 tag is already pushed, create a new 6.1.1 release with the fix
    3. we don't bother with binaries for 6.1.0 but do 6.1.1 instead

    Thoughts?


    For 1) see #3931 to loosen the epsilon for FreeType 2.10.

  12. aclark4life commented on Jul 1, 2019

    @aclark4life
    Member

    @hugovk How about delete the tag and just release 6.1.0? Any downside to that?

  13. hugovk commented on Jul 1, 2019

    @hugovk
    Member

    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.

  14. hugovk commented on Jul 1, 2019

    @hugovk
    Member

    Could just delete it quickly now and hope for the best?

  15. 12 remaining items

  16. aclark4life commented on Jul 1, 2019

    @aclark4life
    Member

    @hugovk Probably fine to wait until tomorrow, thanks for all the hard work! Much appreciated.

  17. nulano commented on Jul 1, 2019

    @nulano
    Contributor

    From the PyPy FAQ:

    The external C-API has been reimplemented in PyPy as an internal cpyext module. We support most of the documented C-API [...]

    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.

  18. aclark4life commented on Jul 1, 2019

    @aclark4life
    Member

    Thanks @nulano

  19. nulano commented on Jul 2, 2019

    @nulano
    Contributor

    #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.

    Our tests didn't pick it up because ... 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 test_imagefont tests are skipped because there's no FreeType (or RAQM) on PyPy3. We should improve these testing gaps.

    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

  20. nulano commented on Jul 2, 2019

    @nulano
    Contributor

    Some new failures on pillow-wheels, TestImageFont.test_unicode_extended failed:

    • Mac MB_PYTHON_VERSION=2.7
    • Linux MB_PYTHON_VERSION=2.7 UNICODE_WIDTH=16
    • Linux MB_PYTHON_VERSION=2.7 PLAT=i686 UNICODE_WIDTH=16

    With:

    • AssertionError: average pixel value difference 14.7190 > epsilon 6.2000
    • AssertionError: average pixel value difference 14.7190 > epsilon 6.2000
    • AssertionError: average pixel value difference 14.7280 > epsilon 6.2000

    https://travis-ci.org/python-pillow/pillow-wheels/builds/552752918

    For 1) see #3931 to loosen the epsilon for FreeType 2.10.

    I suspect this is actually a real failure. When I tried the test on Windows without the #3780 fix, I got the same values:
    E AssertionError: 2.5 not greater than or equal to 14.728 : average pixel value difference 14.7280 > epsilon 2.5000
    https://ci.appveyor.com/project/nulano/pillow/builds/23676028/job/jjd897m8b68sx96a#L6647.

    I suggest reverting #3931 and changing the test's skip conditions to skip on all platforms when running Python 2.

  21. nulano commented on Jul 2, 2019

    @nulano
    Contributor

    I suggest reverting #3931 and changing the test's skip conditions to skip on all platforms when running Python 2.

    Done in #3936.

  22. hugovk commented on Jul 2, 2019

    @hugovk
    Member

    Thanks @nulano! Let's merge #3936 after the release to minimise changes, as it only changes a single test file.

    @cgohlke Please could you test #3935? If it's fine, I'll merge it and continue the release.

  23. nulano commented on Jul 2, 2019

    @nulano
    Contributor

    Regarding #3935, I just realized PyPy does support the new PyUnicode_READ_CHAR function (used with basic layout), but not PyUnicode_AsUCS4Copy (used with raqm layout). In the PR I removed them both for PyPy.

    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?

  24. hugovk commented on Jul 2, 2019

    @hugovk
    Member

    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.

  25. cgohlke commented on Jul 2, 2019

    @cgohlke
    Contributor

    could you test #3935?

    #3935 builds OK with pypy3 on Windows.

  26. hugovk commented on Jul 2, 2019

    @hugovk
    Member

    #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?

  27. cgohlke commented on Jul 2, 2019

    @cgohlke
    Contributor

    could we have Windows binaries for 6.1.0?

    Here you go.

  28. hugovk commented on Jul 3, 2019

    @hugovk
    Member

    🚀Pillow 6.1.0 is released! Thanks everyone for the help.

    Edit: https://twitter.com/PythonPillow/status/1146339393046814721

  29. unpinned this issue on Jul 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions