RLS: 1.1

[TomAugspurger]

Tracking issue for the 1.1 release. I've set the target for July 15th. https://github.com/pandas-dev/pandas/milestone/68

Planning a release candidate for sometime in early July, 1-2 weeks before the final release.

List of open regressions: https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3ARegression
List of open blockers: https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3Ablocker+

[TomAugspurger]

@pandas-dev/pandas-core there's a lot of regressions at https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.1+label%3ARegression, performance and correctness. If people have time then those are relatively high priority.

[jorisvandenbossche]

Sorry that I can't help that much with the 1.1 release; we're also in busy almost-release modus in Apache Arrow for its 1.0 release (August will be better, but that of course doesn't help with getting an RC out in July .. )

[simonjayhawkins]

@TomAugspurger do the performance regressions need to be addressed before the rc? see #35186 (comment)

[jorisvandenbossche]

Ideally as much as possible, I would say, although we probably won't be able to do all. But we should decide a bit on priority regarding the severity of the regression, I would say (factor of slowdown / importance of functionality).
Eg the PR you link to gives only around 20% speed-up, I think?

We can maybe use the "blocker" tag to indicate which regressions are most critical (I'm already using that for non-performance regressions as well)

[simonjayhawkins]

The reason I ask, is that after the rc we could open PRs directly against the 1.1.x branch instead of master and therefore reverting things may be more palatable.

[jreback]

yes we could do that

[jreback]

@pandas-dev/pandas-core please do not put any more PRs / issue on 1.1. let's focus on merging these. On a case-by-case can add but do not do by default.

[TomAugspurger]

What are people thoughts with releasing 1.1.0.rc0 soonish (say Thursday or Friday), which will include known regressions, with a soft plan to release 1.1.0.rc1 with the regressions fixed next week (assuming they're fixed by then)? That gets the release rolling, but gives us a bit of time to wrap things up.

And if the regression fixes are deemed small enough, and there aren't any major reports with the RC0, we can just skip RC1 and do the final release in a couple weeks?

[WillAyd]

I am ok with it though I won’t be available starting Thursday for a few days to help - I signed up to during the group call but unfortunately can’t!

…

Sent from my iPhone

On Jul 14, 2020, at 12:18 PM, Tom Augspurger ***@***.***> wrote:  What are people thoughts with releasing 1.1.0.rc0 soonish (say Thursday or Friday), which will include known regressions, with a soft plan to release 1.1.0.rc1 with the regressions fixed next week (assuming they're fixed by then)? That gets the release rolling, but gives us a bit of time to wrap things up. And if the regression fixes are deemed small enough, and there aren't any major reports with the RC0, we can just skip RC1 and do the final release in a couple weeks? — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jreback]

+1 on this week

[TomAugspurger]

FYI, I'll probably cut 1.1.0rc0 sometime this afternoon. We have a few outstanding issues and PRs but I think those can be solved in the RC period (perhaps with an rc1 if needed).

@pandas-dev/pandas-core We need to decide on a branching strategy during the RC period. Are we ready to start 1.2 development (and so get stuff to 1.x through backports)? Or are we going to wait to split 1.1.x until later? If we have a bunch of stuff ready for 1.2.x we can do the backports, otherwise I think they're just additional noise.

[jreback]

i thought we always waited to branch after 1.1 is actually released but either way in reality is fine with me (just me a bit more for backports)