Release 0.630 planning

[ilevkivskyi]

I would like to release mypy 0.630 on Friday September 7 September 14. The release branch is going to be was cut on Tuesday September 4 Friday September 5. Please mention here any issues and PRs that you would like to include in the release.

Here is the list of release blockers:

• Importing packages can poison the mypy cache. #5534
• Mypy fails on Union[float, int] + Union[float, int] #2128
• Use package_data to ship typeshed and xml files #5517
• --disallow-incomplete-defs does not print errors when run without this argument previously #4913
• Add a customize_class_mro plugin hook #4567
• Perf regression caused by #5474 #5514 (last remaining blocker)
• Regression since 0.620: Argument 1 to "__div__" of "int" has incompatible type "float"; expected "int" #5557
• Remove the 'rop will not be called' error message #5571
• Regression caused by #5565 #5573
• -2 and --python-version 2.7 arguments differ in behaviour #5576 (Is this really important?)
• mypy error trying to check pymc3 #5560 (we don't have time for this and this is not a regression)
• False positive for overriding decorated method in an import cycle #5548 (ditto)

[ilevkivskyi]

I think these two should be fixed before the release: #5534 and #2128

[emmatyping]

I would like to get #5517 in, as it makes finding typeshed a lot simpler and more robust.

[Michael0x2a]

I was just about to mention #2128, actually -- I'm currently in the process of writing some code to resolve that issue and hope to submit a PR either later today or sometime tomorrow.

[srittau]

Is there any chance to have #4913 fixed in the release? Guido's comment seems to indicate it is an easy fix, although I can't judge this.

[gvanrossum]

Maybe #4567? It's a plugin hook for MRO calculation that some user would like to see. I think it's unobjectionable, though it currently has a non-trivial conflict (you edited the same code in your most recent fix or MRO-related issues).

[ilevkivskyi]

I think it also makes sense to fix #5514

[JelleZijlstra]

In general, it would be good to sync typeshed right before creating the branch, so that people's typeshed fixes make it in. Maybe that could be part of the standard release procedure.

[ilevkivskyi]

Maybe that could be part of the standard release procedure.

This is in our internal team playbook. I will make a sync on Monday probably.

[gvanrossum]

A regression: #5557.

[Michael0x2a]

This is cutting it close to the deadline (sorry!), but it'd be nice if #5571 could also be merged in. (It partially addresses some of the feedback regarding error messages in #5557).

[ilevkivskyi]

#5573 should be fixed before the release.

[gvanrossum]

I suspect #5576 may be worth fixing?

At this point we should probably consider postponing the release by a few business days.

I'd also like to see a consolidated list of all issues and PRs that are blocking the release.

[ilevkivskyi]

I'd also like to see a consolidated list of all issues and PRs that are blocking the release.

I updated the description with a list.

I suspect #5576 may be worth fixing?

Why is this important? This release is already late, I would limit ourselves to only critical things.

At this point we should probably consider postponing the release by a few business days.

Yes, I think we can do it on Monday-Tuesday. However, if there are no additional things I would cut release branch tomorrow.