-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release Pillow 4.0.0 on Jan 1, 2017 #2244
Comments
That bikeshed won't paint itself. So: We don't really have a formal policy, other than a tradition to use a major.minor.micro versioning. We update the micro version for https://github.com/python-pillow/Pillow/blob/master/RELEASING.md#point-release for security, installation or critical bug fixes, but we're not covering the micro number here. We're not following semantic versioning, as we release quarterly with whatever has been merged, which inevitably contains both functionality added in a backwards-compatible manner (semver minor bump) and backwards-compatible bug fixes (semver micro bump). We generally try to avoid incompatible API changes (semver major bump), but they sometimes come along too. I'm not too bothered about 3.5.0 or 4.0.0, but here's some pros and cons. Reasons for 3.5.0:
Reasons for 4.0.0:
More welcome for either version. |
I am pro "make the version number noticeably different so folks notice the change". There are likely some projects in which I'd prefer sequential "don't draw attention" versioning, but Pillow is probably not one of them. |
Is this the "release 3.5 (or 4) on Jan 1 2017" issue? If so, can we standardize the title? E.g. "Release Pillow VERSION on DATE"? |
🏏 s… Do we have any consensus on 3.5 vs. 4? Note that while I've stated my opinions, I'm not doing all the work so I can easily be overridden. But please let me know because I want to update the milestones, etc. |
I was leaning to 4.0. I think that's the general consensus, and there are no objections that I've heard. |
Will this add support for Python 3.6? |
@gpraceman I believe so, yes. When in doubt, check the master branch. |
I'm ready to increment the version and tag 4.0. @cgohlke Do you need the source uploaded to Pypi to build? I'm thinking that we might avoid some questions if we tag and build, then upload binaries at the same time as source. |
@cgohlke Works for me. Thanks for building for us. |
Tagged, OSX and Linux wheels built, but without the PR for libpng. (which is odd, unless it's a dependency of one of the dependencies, because it's not required for the library) |
Having never uploaded anything to PyPI myself before, I'm not really familiar with the jargon (also, it looks like some messages were deleted from this thread?) and now I'm a little confused about the version change vs. the new version of Pillow not (yet) being available on PyPI. Maybe one of you could help? |
@cgohlke I assume you fixed up the typo'd version number manually? I'm rebuilding the other wheels now, and will upload when they're done. |
@kerstin The new Pillow 4.0.0 release is in progress now, and will be up on PyPI later today. |
@hugovk Thank you! |
Everything but the source .zip was uploaded to pypi, that one is failing with: At any rate, we're released. |
Had you already uploaded a source zip before fixing the typo? I believe you cannot upload a filename that's already been uploaded, even if it was deleted: pypa/packaging-problems#74 |
@hugovk Sounds familiar, maybe we need a 4.0.1 ? |
Nope, it failed on the first twine upload. |
That might be on purpose. There is already one source distribution, Pillow-4.0.0.tar.gz. |
Maybe @dstufft knows if that's been implemented yet. If so, then I guess we should use only zip from now on? |
It is implemented, you have to pick either a single |
We've been uploading both because different packagers have requested source dists in their native compression -- |
I've spent zero time thinking about this but at a glance it seems like an odd restriction that's going to cause our project trouble for dubiously "good" reasons… not to mention the ensuing bikeshed discussion: how about bzip2 instead of gzip? And so on… |
The PEP already dealt with the bikeshed for the most part, you can't pick bzip2 or xz or anything but The benefit of having a single sdist is it completely eliminates a class of problems that relate to what happens if you have two sdists with different contents. |
@dstufft |
@dstufft It's not very clear that "HTTPError: 400 Client Error: Duplicate file upload detected" in this case means "Duplicate source file upload detected, ignoring .zip or .tar.gz extensions." Perhaps a clearer message and/or adding "See PEP 527" would help others in the future. Thanks! |
Yea, Warehouse has a better error message, I just hadn't done so on legacy PyPI yet. |
Is this right to be closed then? |
Just my 2c, but given the non-semver versioning it'd be really useful for external consumers of the library if CHANGES.rst highlighted backwards incompatible changes. I don't mind reading through, but a lot of the changes don't mean much to me and it's hard to tell if upgrading to 4.0 will break things terribly. (On a related note, if semver were respected, I would just stay within minor patches and upgrade major versions less frequently, so it'd be less of a problem.) |
Significant changes are noted in the release notes: http://pillow.readthedocs.io/en/4.0.x/releasenotes/4.0.0.html |
@joshma Where do you see "non-semver" (aside from ad hoc bump to 4)? If I understand correctly, we mostly adhere to "semver". |
@wiredfool thanks for pointing me to those, didn't realize there were two sources @aclark4life Yeah, I think I picked the wrong term there, you're right. A few pieces around versioning:
|
Generally:
|
The text was updated successfully, but these errors were encountered: