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.4 #41957

Closed
simonjayhawkins opened this issue Jun 11, 2021 · 84 comments
Closed

RLS: 1.4 #41957

simonjayhawkins opened this issue Jun 11, 2021 · 84 comments
Labels
Milestone

Comments

@simonjayhawkins
Copy link
Member

Tracking issue for the 1.4 release. (it's possible we make this 2.0 at some point - not determined yet)

https://github.com/pandas-dev/pandas/milestone/86

Currently scheduled for December 31, 2021 (with a release candidate around 2 weeks before)

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

@simonjayhawkins simonjayhawkins added this to the 1.4 milestone Jun 11, 2021
@simonjayhawkins
Copy link
Member Author

@pandas-dev/pandas-core @pandas-dev/pandas-triage

@rhshadrach
Copy link
Member

Is this a good place to discuss whether it should be 1.4/2.0? Or should a new issue be opened?

@simonjayhawkins
Copy link
Member Author

here is fine imo. but not knowing how big a discussion it would be, opening a new issue is also fine by me.

@rhshadrach
Copy link
Member

rhshadrach commented Jul 2, 2021

I'm +1 on 2.0 Changed - see below

@jbrockmendel
Copy link
Member

whether it should be 1.4/2.0?

Has there been a discussion about unannounced API changes (e.g. deprecations that didn't make it into 1.3)? I'm thinking of #41943 and some MultiIndex behavior that I would want to deprecate if we're doing a 1.4.

@jorisvandenbossche
Copy link
Member

some MultiIndex behavior that I would want to deprecate if we're doing a 1.4.

I think it is OK to do such deprecation if you want to look at that now, regardless of the final decision on 1.4 vs 2.0 (if it ends up becoming 2.0, the deprecation would then stay the full 2.x cycle I guess, like deprecations done in later 2.1 etc releases)

@rhshadrach
Copy link
Member

rhshadrach commented Jul 23, 2021

Agree with @jorisvandenbossche - while we can make breaking changes in 2.0, I'd prefer having a deprecation first (at least in general - perhaps a special case may be warranted). By deprecating, we allow user feedback before a removal/change takes place.

I'm changing my vote above, I'm +1 on 1.4 (but okay with 2.0 too). There are some apply deprecations I would like to get in so that things can start to be fixed in 2.0.

@jbrockmendel
Copy link
Member

IIRC on last week's call we were leaning towards doing a 1.4

@lithomas1
Copy link
Member

#42587 forces us to have a 1.4, since it changes the empty series deprecation warning from a DeprecationWarning to a FutureWarning. If we want to do 2.0, we'd have to revert that(not sure though if its ok to deprecate something with only a DeprecationWarning).

@auvipy
Copy link

auvipy commented Nov 11, 2021

#42587 forces us to have a 1.4, since it changes the empty series deprecation warning from a DeprecationWarning to a FutureWarning. If we want to do 2.0, we'd have to revert that(not sure though if its ok to deprecate something with only a DeprecationWarning).

going with 1.4 would be a sane idea

@attack68
Copy link
Contributor

I was hoping to raise a FutureWarning for the DataFrame.to_latex and DataFrame.to_html (and possibly DataFrame.to_string) methods to utilise the Styler implementation and to do away with the HTMLFormatter and LateX Formatter classes. That would be for 2.0, though, and currently those warnings would have to be in 1.4

@h-vetinari
Copy link
Contributor

h-vetinari commented Dec 12, 2021

Regarding breaking changes, is there any appetite whatsoever to fix the return type of Series.unique, cf. #24108? I didn't manage to get all things into place before 1.0.

@jreback
Copy link
Contributor

jreback commented Dec 12, 2021

@h-vetinari yes that would be a change that would be good to make on a breaking release

@lithomas1 lithomas1 changed the title RLS: 1.4/2.0 RLS: 1.4 Dec 16, 2021
@lithomas1
Copy link
Member

lithomas1 commented Dec 16, 2021

On infra side, we should merge the following at MacPython/pandas-wheels(in the following order):

cc @simonjayhawkins

@jreback
Copy link
Contributor

jreback commented Dec 20, 2021

@simonjayhawkins we can list any blocking issues here

iirc the only important one (which we may not have an issue for) is the pd.NumericIndex removal

cc @jorisvandenbossche

otherwise i think ok to cut the RC soon

@jbrockmendel
Copy link
Member

I'll spend some time tomorrow to see if there's any deprecations we should try to get in.

@simonjayhawkins
Copy link
Member Author

On infra side, we should merge the following at MacPython/pandas-wheels(in the following order):

we don't want to merge these if we need to do another 1.3.x release. It's been a week since 1.3.5 was released and if none of the issues raised so far warrant another release, we can start to think about merging those PRs.

@auvipy
Copy link

auvipy commented Dec 21, 2021

numpy https://github.com/numpy/numpy/releases/tag/v1.22.0rc3 compat could be addressed to

@jreback
Copy link
Contributor

jreback commented Dec 21, 2021

numpy https://github.com/numpy/numpy/releases/tag/v1.22.0rc3 compat could be addressed to

can u be more precise @auvipy

@simonjayhawkins
Copy link
Member Author

Potential deprecations to get in for 1.4

Thanks @jbrockmendel. can you also add the blocker for rc where appropriate (on issues and PRs)

https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3A%22Blocker+for+rc%22

Changes between the rc and the release should be minimal. ideally only issues that cropped up with the rc.

@attack68
Copy link
Contributor

@jbrockmendel
Copy link
Member

Marked #38240, #39584, #44353 as blockers for rc. In each case we need to to come to a decision about the desired behavior.

@jreback
Copy link
Contributor

jreback commented Dec 24, 2021

there are simply too many open issues that are 'blocking' the rc: https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3A%22Blocker+for+rc%22

so my suggestions are:

  • release the rc now and then have a 1.5 where we actually try to address these issues
  • wait x weeks to try to fix this where x <= 2
  • kill a significant number of these and in 2 weeks release the rc.

cc @pandas-dev/pandas-core

@jbrockmendel
Copy link
Member

jbrockmendel commented Dec 24, 2021

kill a significant number of these and in 2 weeks release the rc.

#44353 and #39584 may be fine with no-action, but we really should get the desired behavior pinned down. I don't want to be stuck with undesired behavior for all of the 2.x series.

#38240 we have a game-plan in that I'm putting together a what-would-it-look-like branch. ETA is "sometime this weekend"

#45038 is easy, i can Just Do It.

#45034 i think is an easy "no", though others will need to weigh in on that.

That just leaves #43206 and #41272 where I don't know what's going on.

@auvipy
Copy link

auvipy commented Dec 25, 2021

what about releasing alpha/beta 1 then rc first?

@simonjayhawkins
Copy link
Member Author

done for 3.8 and 3.9. 3.10 outstanding.

@simonjayhawkins
Copy link
Member Author

3.10 outstanding.

conda-forge/pandas-feedstock#126

@simonjayhawkins
Copy link
Member Author

The conda-forge packages have now been up for 24hrs and the PyPI wheels for a couple of days. As there have been no reports of installation issues, will announce shortly if no objections.

@jorisvandenbossche jorisvandenbossche pinned this issue Jan 12, 2022
@simonjayhawkins
Copy link
Member Author

Job has been terminated due to insufficient credits balance on travis builds. This is the arm builds.

aarch64 wheels now uploaded to PyPI

@bashtage
Copy link
Contributor

Might consider building aarch64 on GitHub using QEMU using cibuildwheel. The big downside is the inability to run the full test suite.

@jmg-duarte
Copy link
Contributor

What is the status on 1.4.0? I have a very specific use case which is fixed by 1.4.0 and I am curious to know a possible release date

@simonjayhawkins
Copy link
Member Author

It was originally scheduled for 2 weeks after the rc date but since the wheels, conda packages and release announcement did not go out straight away, giving it a couple of extra days. So assuming no blockers, sometime in the next few days (probably Sunday)

@jreback
Copy link
Contributor

jreback commented Jan 20, 2022

@simonjayhawkins all PRs have been merged (pending 2 backports). I would move all issues off of 1.4

@simonjayhawkins
Copy link
Member Author

There are a couple of things i'm about to look into:

from #45464

Also backport #45257 & #45323 since this PR sits on top of them and it makes sense to do so.

or how to get CI to green on 1.4.x (if it is something else)

also #45473 looks iffy to me at first glance with regards to the change in the na_rep keyword behavior (maybe just need some clarification in the docs)

@simonjayhawkins
Copy link
Member Author

I would move all issues off of 1.4

created 1.4.1 milestone https://github.com/pandas-dev/pandas/milestone/93 scheduled for February 13, 2022 (i.e. 3 weeks from Sunday) but date would be flexible on severity of any reported regressions

@simonjayhawkins
Copy link
Member Author

or how to get CI to green on 1.4.x (if it is something else)

the last green build was #45458

actions-38-minimum_versions seems to be failing regularly on 1.4.x but with a different tests. The failure is a unexpected ResourceWarning that was occurring before we forked. This no longer occurs on master and AFAICT #45204 fixed so will need backport.

The other failures are timeouts which also occur on master. #45500 is investigating

from #45464

Also backport #45257 & #45323 since this PR sits on top of them and it makes sense to do so.

if not the cause of the CI failures does not strictly need backport but oth prob no harm in backporting those.

@simonjayhawkins
Copy link
Member Author

simonjayhawkins commented Jan 21, 2022

release checklist

restarted a run that failed on a flakey test. no reason to believe that won't pass on the restart

I will open a PR shortly to tidy these up and set the release date to tomorrow so that if we are in a good state to start the release tomorrow morning (UK time) we can release tomorrow.

I’ve not built the pdf locally (to check docs build correctly with release scripts) since #45370 (last dummy release performed earlier this week did include #45195). Will hopefully do that today.

greenish

The 1.4.0 release will be short lived with a 1.4.1 release in around 3 weeks or less, so no reason to block on these. However, from #45470 (comment)

The fix should be relatively straightforward I think

So maybe could get that one sorted before release

@jorisvandenbossche
Copy link
Member

jorisvandenbossche commented Jan 21, 2022

@simonjayhawkins I would ask to wait a bit longer to release. Yesterday you said "probably Sunday", so I planned on that and am doing some fixes today for remaining regressions.

Update: now read your message fully, and you mention to release tomorrow. That should give some time to still get in 1.4.0 PRs today, so that's fine.

@simonjayhawkins
Copy link
Member Author

Yeah let's aim for tomorrow and accept that if we are not ready we can do it Sunday. If we aim for Sunday, it may stretch into next week.

@jreback
Copy link
Contributor

jreback commented Jan 21, 2022

@jorisvandenbossche

pls don't add anything else to 1.4

@simonjayhawkins
Copy link
Member Author

[x] no open issues/PRs (except this one) https://github.com/pandas-dev/pandas/milestone/86

closing milestone to new additions. please do not merge anything to 1.4.x

@simonjayhawkins
Copy link
Member Author

same timeouts as on master. will assume green.

@simonjayhawkins
Copy link
Member Author

simonjayhawkins commented Jan 22, 2022

so that if we are in a good state to start the release tomorrow morning (UK time) we can release tomorrow.

starting release now

@simonjayhawkins
Copy link
Member Author

have done this manually to also remove the 3.7 builds so will close the bot generated PR once opened

conda-forge/pandas-feedstock#127

@rhshadrach
Copy link
Member

For the new versions dropdown in the docs, I'm getting 1.3 (stable) takes me to 1.4, and the 1.4 dropdown is still showing "(rc)".

cc @jorisvandenbossche

@simonjayhawkins
Copy link
Member Author

The website https://pandas.pydata.org/ still shows 1.3.5 as the latest release. This doesn't get updated until a merge to main after the release. Maybe the same for the docs dropdown?

@simonjayhawkins
Copy link
Member Author

wheels and conda packages now available. will announce tomorrow if no serious installation issues reported.

@simonjayhawkins
Copy link
Member Author

For the new versions dropdown in the docs, I'm getting 1.3 (stable) takes me to 1.4, and the 1.4 dropdown is still showing "(rc)".

a brief look at #45370 and I guess web/pandas/versions.json needs to be updated manually

@jorisvandenbossche
Copy link
Member

Thanks for the release, Simon!

For the new versions dropdown in the docs, I'm getting 1.3 (stable) takes me to 1.4, and the 1.4 dropdown is still showing "(rc)".

a brief look at #45370 and I guess web/pandas/versions.json needs to be updated manually

Yes, that's correct, and I see you already did that in the meantime (#45555). We should probably add that somewhere to the release checklist

@lithomas1
Copy link
Member

Can we close this issue now?

@lithomas1 lithomas1 unpinned this issue Jan 27, 2022
@jreback jreback closed this as completed Jan 27, 2022
@simonjayhawkins simonjayhawkins mentioned this issue Apr 14, 2022
1 task
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