Skip to content

Release mypy 0.521 #3732

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

Closed
gvanrossum opened this issue Jul 18, 2017 · 24 comments
Closed

Release mypy 0.521 #3732

gvanrossum opened this issue Jul 18, 2017 · 24 comments
Assignees

Comments

@gvanrossum
Copy link
Member

gvanrossum commented Jul 18, 2017

We're going to try and release a bugfix release for 0.520, dubbed 0.521. The plan is to do this relatively quickly, using a release branch forked from v0.520, cherry-picking only essential fixes for announced features and for regressions since 0.510. I am going to be the release manager. We will have a new blog post. I'm aiming to do the release on Monday 7/24.

I plan to also create a release branch for typeshed, so we can cherrypick typeshed commits as well.

If you have a mypy or typeshed bugfix (already merged on master) that should really go in please mention it here (I have a few in mind already).

@ilevkivskyi
Copy link
Member

I think #3680 could go in. It fixes a high priority issue (probably because this is "incompleteness" in an announced feature).

@gvanrossum
Copy link
Member Author

I think #3680 could go in.

I'm not so sure, it's not even merged in master.

@ilevkivskyi
Copy link
Member

I'm not so sure, it's not even merged in master.

OK, sorry I misunderstood you, I thought you meant PRs that might go in.

@gvanrossum
Copy link
Member Author

I do have a question for @ilevkivskyi. Should #3700 and its fix, #3719, go in? This fixes a crash (on something that was merely an error in 0.511); but the fact that the fix needed a fix is a bit worrysome.

@ilevkivskyi
Copy link
Member

Should #3700 and its fix, #3719, go in? This fixes a crash (on something that was merely an error in 0.511); but the fact that the fix needed a fix is a bit worrysome.

I would say rather yes than no. Although this touches a "fundamental" thing -- the lookup function.
Concerning the fix that needed a fix, yes first time I didn't really made a "semantically equivalent" transformation, my fault. Also note that the initial crash itself is caused by an assert in one of the --strict-optional PRs. I think we will see more crashes like this in nearest future that are subtle to fix, but this is probably how --strict-optional works in general -- adding asserts finds some corner cases in the logic.

@gvanrossum
Copy link
Member Author

OK, makes sense. Added them.

@gvanrossum
Copy link
Member Author

Also, note that this is not a feature freeze for master! Just perhaps don't land sweeping refactors since they might complicate cherry-picking bug fixes into the release branch.

@gvanrossum
Copy link
Member Author

Two pending fixes that should go in:

@JelleZijlstra
Copy link
Member

From typeshed I think we should include only 7637549, which fixes a regression in csv.DictReader, python/typeshed#1475. I looked at commits since 0e26c1f, the version of typeshed that was released with 0.520.

@gvanrossum
Copy link
Member Author

From typeshed I think we should include only 7637549

Thanks, that was my conclusion too, and I've already cherry-picked it!

@graingert
Copy link
Contributor

Also python/typeshed@2bb7ea9

@gvanrossum
Copy link
Member Author

@graingert

Also python/typeshed@2bb7ea9

Hm, that's python/typeshed#1478 -- is that also a regression? We're trying to exercise an abundance of caution here, so the default is not to cherry-pick anything unless it worked in 0.510 but is broken in 0.520.

@graingert
Copy link
Contributor

I believe it was, I haven't had time to verify 100%

@graingert
Copy link
Contributor

graingert commented Jul 24, 2017

@gvanrossum yes this is a regression from 0.511 (edit: and of course 0.510 because they use the same typeshed version).

@gvanrossum
Copy link
Member Author

OK I've cherrypicked it.

@graingert
Copy link
Contributor

@gvanrossum ok great, thanks!

@gvanrossum
Copy link
Member Author

Status update: the release is out on PyPI and tagged as v0.521. I'm keeping this issue open until we've updated the blog post, which will probably happen tomorrow.

@Deimos
Copy link
Contributor

Deimos commented Jul 25, 2017

Could you please update the homepage at http://mypy-lang.org/ as well? I didn't realize there was a blog post for 0.520 since it isn't in the What's New section there and I didn't check the blog directly.

@gvanrossum
Copy link
Member Author

gvanrossum commented Jul 25, 2017 via email

@graingert
Copy link
Contributor

@gvanrossum 0.521?

@gvanrossum
Copy link
Member Author

Yeah, blame cell phones and my poor proofreading skills. ;-)

In retrospect I think we should've posted the 0.520 blog post to the website even though we realized soon there were some regressions. Jukka has long gone to bed (he's in Finland). Tomorrow (in the am US time) we'll upload a new (minimal) blog post and updated the website.

@gvanrossum
Copy link
Member Author

Well, the blog post is up (http://mypy-lang.blogspot.com/2017/07/mypy-0521-released.html) and the website is updated (http://mypy-lang.org/), so I'm closing this. I'm still considering whether to merge #3762.

@graingert
Copy link
Contributor

I'm still considering whether to merge #3762.

So you can see what this would look like, I created a merge commit using git-reparent: graingert@7ad6133

@gvanrossum
Copy link
Member Author

Glad that it turns out to be null merge (presumably because I cherry-picked the little doc update back). I then propose to not merge the branch, since release branches are, well, branches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants