Skip to content
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

RLS: 1.1 #34730

Closed
TomAugspurger opened this issue Jun 12, 2020 · 29 comments
Closed

RLS: 1.1 #34730

TomAugspurger opened this issue Jun 12, 2020 · 29 comments
Labels
Milestone

Comments

@TomAugspurger
Copy link
Contributor

TomAugspurger commented Jun 12, 2020

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 TomAugspurger added this to the 1.1 milestone Jun 12, 2020
@TomAugspurger
Copy link
Contributor Author

@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
Copy link
Member

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
Copy link
Member

simonjayhawkins commented Jul 9, 2020

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

@jorisvandenbossche
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor

jreback commented Jul 9, 2020

yes we could do that

@jreback
Copy link
Contributor

jreback commented Jul 13, 2020

@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
Copy link
Contributor Author

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
Copy link
Member

WillAyd commented Jul 14, 2020 via email

@jreback
Copy link
Contributor

jreback commented Jul 14, 2020

+1 on this week

@TomAugspurger
Copy link
Contributor Author

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
Copy link
Contributor

jreback commented Jul 17, 2020

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)

@simonjayhawkins
Copy link
Member

my preference would be to branch immediately with rc0 and only backport the minimum, but no strong preference

@TomAugspurger
Copy link
Contributor Author

TomAugspurger commented Jul 17, 2020

Planning to tag the rc after merging

any others we consider blockers?

@TomAugspurger
Copy link
Contributor Author

Going to get started on RC0 now. Ping me if there's anything you want me to hold up for.

@simonjayhawkins
Copy link
Member

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

we need to firm up the decision in order to label PRs correctly. at least before we merge anything to master.

@WillAyd
Copy link
Member

WillAyd commented Jul 21, 2020

Is this still outstanding? FWIW I would suggest the simplest route, so wait to split until 1.1 is released. Hopefully we don't have a huge window between the RC and actual release so I don't think we gain a lot by splitting at RC

@simonjayhawkins
Copy link
Member

the downside is we shouldn't be merging anything to master (except regression fixes).

This affects authors of new PRs since we can't add a release note without 1.2 whatsnew

and affects momentum on refactoring were people (myself, I suspect @jbrockmendel and probably others) that are waiting for PRs to be merged before submitting further PRs.

This affects reviewing, since we can't yet ask PR authors to move the release notes from 1.1 to 1.2.

@TomAugspurger
Copy link
Contributor Author

@pandas-dev/pandas-core things seem pretty quite w.r.t. 1.1.0rc0. How do people feel about a release early this week, today or tomorrow?

The main outstanding issue(s) are around DataFrame.__setitem__ mutating arrays inplace or not.

#34271 is also closeish, but I'd probably prefer pushing it to 1.1.1.

@jreback
Copy link
Contributor

jreback commented Jul 27, 2020

sgtm - i will be unavail for next day or 2 - so go ahead with what is needed

@TomAugspurger
Copy link
Contributor Author

I'm planning to look at #35429 briefly and will hopefully get a PR up soon.

After that I'm planning to start work on the release.

@TomAugspurger
Copy link
Contributor Author

Actually, not going to work on #35429, since we need to discuss the expected output.

@TomAugspurger
Copy link
Contributor Author

Starting the release.

@TomAugspurger
Copy link
Contributor Author

Wheels are up and conda-forge packages should be available soon. Thanks all!

@TomAugspurger
Copy link
Contributor Author

@simonjayhawkins FYI, I'll push a branch for 1.1.x now.

@simonjayhawkins
Copy link
Member

simonjayhawkins commented Jul 28, 2020

and we need a v1.2.0.dev0 tag?

@TomAugspurger
Copy link
Contributor Author

Oh yeah, I'll push one.

@TomAugspurger
Copy link
Contributor Author

d1b1faa

@simonjayhawkins
Copy link
Member

Thanks Tom

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

No branches or pull requests

5 participants