Tracking issue for the 2.0 release.

Note: pandas 2.0 is the next major release in the pandas semver-like release cycle and different from some historical discussion about the pandas future also named pandas 2.

Blockers

[x] https://github.com/pandas-dev/pandas/pull/50939

Scheduled

Feb 2023

References

Milestone: https://github.com/pandas-dev/pandas/milestone/42
Deprecations list: #30228
Breaking changes: #44823

Comment From: simonjayhawkins

we don't have a master tracker for deprecations that should be in a released pandas before we release 2.0.

There are currently 91 issues labeled deprecate https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3ADeprecate, so need to start whittling this list down.

Comment From: jbrockmendel

A few things on my radar screen that I think need to change in 2.0, which in many cases means deprecating in 1.5:

[ ] #44353 -> #45333
[ ] #41626
[ ] #37643

Comment From: mroeschke

we don't have a master tracker for deprecations that should be in a released pandas before we release 2.0.

There are currently 91 issues labeled deprecate https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3ADeprecate, so need to start whittling this list down.

My interpretation is that issues labeled deprecate doesn't necessarily mean they need to all be decided upon (yes & implemented or no) by 2.0; just that they are up for consideration anytime.

Comment From: rhshadrach

Agreed @mroeschke. I've been tagging deprecation issues where the conversation makes it clear there is no consensus as "Needs Discussion". There are currently only 46 issues that are tagged deprecation but not needs discussion. Maybe it'd be reasonable to whittle down this list by either (a) implementing or (b) tagging as needs discussion.

https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3ADeprecate+-label%3A%22Needs+Discussion%22

Comment From: lithomas1

@pandas-dev/pandas-core Are there any objections for the next release to be 2.0?

Comment From: phofl

I think the agreement on the august call was to wait with the final decision till 1.5.1 is out in case anything unexpected happens

Comment From: mroeschke

As mentioned by @lithomas1 on Slack, do folks think we should push a 2.0.0.dev0 tag now that 2.0 is agreed to be the new version? The reasoning is to help downstream nightly/main users pin as we start enforcing deprecations.

Comment From: datapythonista

I updated this issue description with the list of blockers for 2.0 I'm aware of (the known deprecations, plus a 1.4 deprecation that was not track or enforced). If there are other blockers to be considered, it'd be good to add them to the list before the call next week, so we can discuss them.

Comment From: mroeschke

Updated the issue description after the outcome of the 2023-01-11 dev meeting (only blocker was the Int/Uint/FloatIndex removal)

Comment From: mroeschke

Updated the issue description after the outcome of the 2023-02-08 dev meeting

@datapythonista would you still be willing to do a 2.0rc release sometime next week assuming the above PRs get merged? @lithomas1 expressed willingness to do a release if you are unable

Comment From: datapythonista

Sorry, I have a conflict, and I'm teaching at the time of the pandas dev call, I won't be able to join them for at least couple of months. But I can do the release when things are ready, and also happy to hand over to @lithomas1 if he prefers to do them. But if needed, no problem to continue doing the releases myself.

Comment From: jbrockmendel

There's a handful of comments # TODO(1.4): Change me to xfails at release time. i guess we should make that change for the 2.0 release?

Comment From: mroeschke

I don't think that should necessarily block a 2.0rc release next week

Comment From: lithomas1

There's a handful of comments # TODO(1.4): Change me to xfails at release time. i guess we should make that change for the 2.0 release?

Those are for the pyarrow csv tests, should be OK to ignore, but I'm getting around to fix them.

Comment From: rhshadrach

It'd be good to get in #51335 for a few reasons (see the linked issues), but not a blocker in my opinion.

Comment From: datapythonista

I think all blockers are now merged. There seems to be a problem with pylint on master. I'll start preparing for the release and fix it if nobody does before, and I'm aiming to tag and release 2.0 RC on Thursday. Feel free to continue merging things until then, but probably worth trying to get PRs rebased more often than usual to avoid problems in master.

Comment From: lithomas1

Wheel builders are currently broken on Windows and uploads don't work on aarch. Can you give till Monday to work things out?

Comment From: lithomas1

I have a PR open for aarch uploads but it'll take until the next nightly to verify it works.

Comment From: datapythonista

Absolutely, I didn't see that, thanks for the heads up. Let's aim next week then, let me know if you need help.

Comment From: lithomas1

aarch nightly uploads are successful (I haven't tested that it triggers on a tag, though. We'd have to do the RC to figure out if that functionality works).

Now, just the Windows failing tests. If we can worked out quickly, then maybe we can release on Friday.

Comment From: lithomas1

@phofl It looks like #50764 is the cause. (I dunno why this is not failing on the other Windows jobs, only difference here is that the Windows jobs for wheel builders are run in a Docker image)

(The wheel builders output dtype of int64 looks more correct) https://github.com/pandas-dev/pandas/blame/main/pandas/tests/frame/test_query_eval.py#L1325

Comment From: lithomas1

All build blockers should be cleared for 2.0.

We could technically release on Thursday as originally planned, but I'd like the nightlies to do another full green run to flush out issues(which will be caught in downstream project's CI).

Comment From: phofl

Yeah I think this is a good idea

Comment From: mroeschke

Yeah releasing Friday (or even Monday) sounds good

Comment From: phofl

Plan is still to release tomorrow?

Comment From: datapythonista

Plan is still to release tomorrow?

Seems like the nightly wheels builds are broken: https://dev.azure.com/pandas-dev/pandas-wheels/_build?definitionId=3

I'll have a look tomorrow, if it's something that can be solved quickly, happy to release tomorrow.

Comment From: lithomas1

Plan is still to release tomorrow?

Seems like the nightly wheels builds are broken: https://dev.azure.com/pandas-dev/pandas-wheels/_build?definitionId=3

I'll have a look tomorrow, if it's something that can be solved quickly, happy to release tomorrow.

The cibuildwheel wheel builders are uploading correctly, so we should release from there.

If everything works correctly, wheels will auto upload to the bucket as soon as you tag and push.

(See e.g. https://github.com/pandas-dev/pandas/actions/runs/4214373874)

Comment From: datapythonista

The cibuildwheel wheel builders are uploading correctly, so we should release from there.

Ah, that's cool. Sorry, I missed we were going to use those for this release already. Is the MacPython repo still useful for anything?

Comment From: lithomas1

Maybe 1.5.4?

Ideally, cibuildwheel should be able to handle tags on any branch, so hopefully it's not necessary.

Comment From: datapythonista

@pandas-dev/pandas-core ready to start the release, but I see that the CI has been broken in main for 4 days (more than 30 commits). Seems like the problem is that quite often pytest doesn't seem to run (I guess the problem is with pytest-xdist, but not sure). This is a sample failed build: https://github.com/pandas-dev/pandas/actions/runs/4223013568/jobs/7332226998#step:8:53

Should we postpone the release until we've got a reliable CI, or does people still want to release with builds not running at each commit?

Comment From: phofl

Yeah this is because of false-positive file leaks that started showing up a while ago, matt has a pr to fix https://github.com/pandas-dev/pandas/pull/51443 but I think we can release anyway, if this does not screw up the release process.

Comment From: datapythonista

That PR didn't seem related. I'll wait a bit to see if there are other opinions, and start the release in couple of hours if there are no objections.

Comment From: phofl

The cancelled builds show up regularly, this is nothing new.

Edit: This is also not every commit, the second commit passed except the file leak problems

Comment From: mroeschke

Yeah https://github.com/pandas-dev/pandas/pull/51443 will fix the non-timeout issues in the CI. Can merge before or after the release.

The CI has been "greenish" for a while, so I don't think more CI work is blocking the RC release

Comment From: datapythonista

Cool, thanks for the feedback. Starting the release, tagging at 3b295c9b4891cd995f40b2bf9856b960e957f73f

Comment From: datapythonista

@pandas-dev/pandas-core please do not merge PRs until I push the new tag. Thank you!

Comment From: datapythonista

@pandas-dev/pandas-core It's ok to merge again. main is now 2.1. For anything that should be in 2.0 please set the milestone to 2.0 so it's backported by our bot.

Comment From: jreback

is there a reason you are not doing a rc tag?

Comment From: datapythonista

is there a reason you are not doing a rc tag?

Do you mean a git tag? I did v2.0.0rc0:

commit 09c6351374ca45ab621f448d0d7d160f0becbd76 (HEAD -> main, tag: v2.1.0.dev0, upstream/main)
Author: Marc Garcia <garcia.marc@gmail.com>
Date:   Mon Feb 20 21:26:33 2023 +0100

    Start 2.1.0

commit 1a2e300170efc08cb509a0b4ff6248f8d55ae777 (tag: v2.0.0rc0, upstream/2.0.x, 2.0.x)
Author: Pandas Development Team <pandas-dev@python.org>
Date:   Mon Feb 20 21:15:15 2023 +0100

    RLS: 2.0.0rc0

Is that what you mean?

Comment From: datapythonista

@lithomas1 not all wheels have completed already, but seems like everything is working just fine: https://anaconda.org/multibuild-wheels-staging/pandas/files?version=2.0.0rc0 (I couldn't try the wheels yet, since the Linux ones didn't finish, but looks good so far).

Great job, thanks for implementing this!

Comment From: jreback

yea that's what i meant @datapythonista ty

Comment From: datapythonista

yea that's what i meant @datapythonista ty

Great. In case it was my previous comment that was misleading, what we've got now is:

A 2.0.0rc0 tag and release (still working on it)
A 2.0.x branch, where we should backport anything for the final 2.0.0 and any future patch release of the 2.0 series

I didn't change anything in the workflow we've been using until now (not that I'm aware of at least). Let's see how things work with the RC, and I guess we can release RC1 or the final 2.0.0 in couple of weeks.

Comment From: phofl

I've added a 2.1 milestone, just as a heads up. @datapythonista you can edit as necessary. Just want to tag stuff correctly

Comment From: datapythonista

I've added a 2.1 milestone, just as a heads up. @datapythonista you can edit as necessary. Just want to tag stuff correctly

Thanks for creating the milestone. I'm taking care of the docs myself, I'll have the whatsnew file for 2.1 shortly.

Comment From: datapythonista

All wheels successfully built. I see that we don't have universal wheels anymore, is that expected @lithomas1 ? Not sure if those were useful, but since it's a RC, uploading the created ones to PyPI.

Comment From: lithomas1

All wheels successfully built. I see that we don't have universal wheels anymore, is that expected @lithomas1 ? Not sure if those were useful, but since it's a RC, uploading the created ones to PyPI.

Yup, looks good to me. universal2 wheels were dropped on purpose since numpy stopped making them (so would be useless for us to have them).

Comment From: datapythonista

PyPI package published, I opened the PR for conda-forge manually (it didn't trigger the PR automatically after many hours last release, not waiting this time). Seems like there is an issue with conda-forge and versioneer I don't see an immediate fix for: https://github.com/conda-forge/pandas-feedstock/pull/154

Docs are already available: https://pandas.pydata.org/pandas-docs/version/2.0/index.html

Comment From: datapythonista

We fixed the versioneer problem, but seems like we've got some genuine test failures in the conda-forge builds. I guess it's a platform specific (ppc64le) bug with dates: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=661871&view=logs&j=696704cc-6fef-57a3-ea36-f27779b8cd5e&t=ed2e6513-0a06-519f-13f9-1e5619642f2a&l=8794

@jbrockmendel do you mind having a look and see if it can be related to the work you've been doing with datetime please?

Comment From: jbrockmendel

Definitely looks datetime-related, but no immediately obvious culprit. I guess we'd need to bisect. Do we not run this on the CI?

Comment From: lithomas1

@datapythonista I think we should merge https://github.com/conda-forge/pandas-feedstock/pull/156 even with ppc64le being red.

We don't have first-class support for ppc64le (and previous conda-forge releases, did not run the pandas test suite), so probably good to go ahead.

Comment From: simonjayhawkins

@datapythonista I think we should merge conda-forge/pandas-feedstock#156 even with ppc64le being red.

yes. can change the build number and re-build if the problem is resolved. So probably best to make the working packages available.

Comment From: simonjayhawkins

or do a rc1 if changes needed on the pandas side.

Comment From: datapythonista

Good point, yes, I don't think many users are going to test the RC for ppc64le anyway. Just merged it, I will announce the RC once the conda-forge packages are ready.

Comment From: datapythonista

conda-forge packages have been generated for all packages except ppc64le, and announcements have been made. Let's see the feedback from the RC, and if everything works well we can probably release 2.0 in two weeks.

Comment From: simonjayhawkins

we have a release notes for 1.5.4 on 2.0.x that would need to be removed before 2.0 release if not doing a 1.5.4 before.

Comment From: datapythonista

we have a release notes for 1.5.4 on 2.0.x that would need to be removed before 2.0 release if not doing a 1.5.4 before.

Good point. At some point we were thinking on potentially release 1.5.4 after 2.0. but what you mention makes it trickier. But I think it was finally decided to skip 1.5.4, since that made the build work easier. Am I right @lithomas1 ?

In any case, any objection to not release 1.5.4, and delete the whatsnew file (and backport the deletion to 2.0.x?

Comment From: MarcoGorelli

not release 1.5.4, and delete the whatsnew file (and backport the deletion to 2.0.x?

+1, happy to let the 1.5.x series sail

Comment From: lithomas1

+1 as well.

Comment From: datapythonista

Plan is to release another RC once #51433 is complete. Let me know if someone else has a blocker, or something that should go into 2.0.0. I think we can get #50936 in too, a tiny change to the docs css that fix a problem in the dark theme.

For the rest, I'm planning to move everything in the 2.0 milestone to a new milestone 2.0.1 shortly, so let me know if you think anything else should be in 2.0.

Comment From: MarcoGorelli

I think it'd be nice to get https://github.com/pandas-dev/pandas/pull/51247 in, which adds tzdata as a dependency for Windows

Not a blocker though

Any ideas on how to address the differing versioning pattern on conda vs PyPI https://github.com/pandas-dev/pandas/pull/51247#issuecomment-1455618193 (or whether it's a non-issue) would be appreciated

Comment From: phofl

I'd be great if you could leave all CoW things on 2.0, they should get into 2.0, but not a blocker for the rc

Comment From: lithomas1

Plan is to release another RC once #51433 is complete. Let me know if someone else has a blocker, or something that should go into 2.0.0. I think we can get #50936 in too, a tiny change to the docs css that fix a problem in the dark theme.

For the rest, I'm planning to move everything in the 2.0 milestone to a new milestone 2.0.1 shortly, so let me know if you think anything else should be in 2.0.

I think it's fine to keep merging stuff into 2.0 other than API changes/new deprecations (so perf improvements and some bug fixes should be fine).

I don't want to rush anything, but ideally we should get the RC out pretty soon.

NEP 29 says that Python 3.8 support is supposed to be dropped on April 14, 2023(~ 1 month away), so we'll want to cut pretty soon (ideally next week/week after that to get the standard buffer in between RC and release).

Comment From: simonjayhawkins

NEP 29 says that Python 3.8 support is supposed to be dropped on April 14, 2023(~ 1 month away), so we'll want to cut pretty soon (ideally next week/week after that to get the standard buffer in between RC and release).

Is there a benefit to delaying the final 2.0 release by a week or two and dropping Python 3.8 support?

It's not so much that we are supposed to drop support on these dates but that we support until at least those dates. Dropping as soon as possible after that date is advantageous to reduce the maintenance burden, e.g. ci, wheel building?

Comment From: phofl

There is still a doc build problem when building with 3.9 or 3.10, I have an open pr about this somewhere if someone wants to take a look

Comment From: datapythonista

Since we've been testing all the commits for 2.0 with Python 3.8, I think it's worth that it supports it.

But we already made the cut from main, and I've been assuming we'll make the second RC from the 2.0.x branch, not from main. Let me know if someone has a different expectation.

If that's the case, I think it's fine to remove 3.8 from main anytime. I think the backports to 2.0.x will continue to be tested against 3.8. Not ideal to find problems with 3.8 in the backports, but I think it should be rare in practice to have any, and we'll have the problem anyway for 2.0.1... if we remove after the final 2.0 release.

Does this make sense?

Comment From: simonjayhawkins

But we already made the cut from main, and I've been assuming we'll make the second RC from the 2.0.x branch, not from main. Let me know if someone has a different expectation.

IMHO a RC should be just that: a candidate for release. Hence why normally I'm keen not to see significant changes from the RC to the actual release once the rc has been made available for users to test.

In some respects, with a second rc all bets are off. So maybe not unreasonable to cut from main and move all the notes from the 2.1 release notes to 2.0.

Comment From: Dr-Irv

Plan is to release another RC once #51433 is complete. Let me know if someone else has a blocker, or something that should go into 2.0.0. I think we can get #50936 in too, a tiny change to the docs css that fix a problem in the dark theme.

For the rest, I'm planning to move everything in the 2.0 milestone to a new milestone 2.0.1 shortly, so let me know if you think anything else should be in 2.0.

I submitted https://github.com/pandas-dev/pandas/pull/51370 a few weeks ago, suggesting it for 2.0 before the first RC came out, but didn't get any review. I did tag it for the 2.0 milestone. It's a new feature. I'll leave it to others whether it is included or not. If you want to include it, I need to fix conflicts introduced since I did the PR.

Comment From: phofl

I'd cut the new rc from 2.0.x

Comment From: phofl

51871 is the last one that should go into the rc. I hope that this is ready now so we should be able to cut the rc soonish

Comment From: MarcoGorelli

https://github.com/pandas-dev/pandas/pull/51247 should be ready, any chance to include that too please? It would be good to see if it fixes the issue for Windows users

Comment From: jbrockmendel

If we can sneak it in, I'd like to nominate #51874

Comment From: datapythonista

No strong opinion on getting those new issue in for the RC. But probably better if we agree on a day for the RC, and if they aren't merged we move forward. What about this Thursday? Any objection?

Comment From: MarcoGorelli

Sounds good, thanks!

Comment From: phofl

Sounds good to me, the dtype_backend pr will be ready later today.

Comment From: mroeschke

Thursday sounds good. Thanks!

Comment From: phofl

The dtype_backend stuff is in, so good to release from my side

Comment From: datapythonista

@pandas-dev/pandas-core We can release once #52012 is merged, but I see we've got two CI failures in 2.0.x (Numpy dev and minimum versions). I think we should fix those errors before moving forward. Anyone having a look at them?

Comment From: phofl

The min versions build is a flaky test, not much we can do there.

The numpy dev failure looks to be addressed in #52010 (mostly except the out of range failure)

Comment From: phofl

Looks like the numpy dev failure was a GitHub actions cache issue. Should be green now

Comment From: datapythonista

Yep, numpy dev finished green in the last build on 2.0.x.

The minimum versions is still failing, this is the error:

__________ TestTableOrient.test_warns_non_roundtrippable_names[idx0] ___________
[gw1] linux -- Python 3.8.0 /home/runner/micromamba/envs/test/bin/python3.8

self = <pandas.tests.io.json.test_json_table_schema.TestTableOrient object at 0x7eff7dffc8b0>
idx = Index([], dtype='object', name='index')

    @pytest.mark.parametrize(
        "idx",
        [
            pd.Index([], name="index"),
            pd.MultiIndex.from_arrays([["foo"], ["bar"]], names=("level_0", "level_1")),
            pd.MultiIndex.from_arrays([["foo"], ["bar"]], names=("foo", "level_1")),
        ],
    )
    def test_warns_non_roundtrippable_names(self, idx):
        # GH 19130
        df = DataFrame(index=idx)
        df.index.name = "index"
        with tm.assert_produces_warning():
>           set_default_names(df)

pandas/tests/io/json/test_json_table_schema.py:624: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
../../../micromamba/envs/test/lib/python3.8/contextlib.py:120: in __exit__
    next(self.gen)
pandas/_testing/_warnings.py:135: in _assert_caught_expected_warning
    _assert_raised_with_correct_stacklevel(actual_warning)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

actual_warning = <warnings.WarningMessage object at 0x7eff522aff40>

    def _assert_raised_with_correct_stacklevel(
        actual_warning: warnings.WarningMessage,
    ) -> None:
        from inspect import (
            getframeinfo,
            stack,
        )

        caller = getframeinfo(stack()[4][0])
        msg = (
            "Warning not set with correct stacklevel. "
            f"File where warning is raised: {actual_warning.filename} != "
            f"{caller.filename}. Warning message: {actual_warning.message}"
        )
>       assert actual_warning.filename == caller.filename, msg
E       AssertionError: Warning not set with correct stacklevel. File where warning is raised: /home/runner/micromamba/envs/test/lib/python3.8/inspect.py !=

Doesn't seem a flaky test to me, maybe I'm missing something. In any case, it shouldn't be a problem to release with it. Any objection to move forward with the second RC withe 2.0.x as it is now?

Comment From: phofl

It's an unclosed File warning that happened on the last 2, the 5 before that were green.

/home/runner/work/pandas/pandas/pandas/tests/io/json/test_json_table_schema.py. Warning message: unclosed file <_io.BufferedRandom name=13>

we see those occasionally, so good to release on my side

Comment From: datapythonista

Ah, thanks for the info, I didn't realize that was the cause of the warning. If there are no further comments I'll start the release in like one hour. Please don't merge anyhing to 2.0.x until further notice. Thanks!

Comment From: datapythonista

pandas 2.0.0rc1 (second RC) has been tagged, and a GitHub release has been created. Waiting for the CI in both this repo and the conda-forge feedstock to continue with the PyPI and conda-forge packages, and to publish the docs.

Comment From: MarcoGorelli

thanks @datapythonista !

Please don't merge anyhing to 2.0.x until further notice

Are we OK to start merging now?

Comment From: mroeschke

It's an unclosed File warning that happened on the last 2, the 5 before that were green.

Just to note, these unclosed files are from matplotlib and not related to us https://github.com/pandas-dev/pandas/issues/44844#issuecomment-995387486

Comment From: datapythonista

PyPI packages already available. Tested for my platform, and everything seems fine. Still waiting for the conda-forge CI to finish (arm builds take longer). If all is green the conda-forge PR will automerge and packages for most architectures should be available in less than one hour.

I'll send an update here and announce the release once most conda-forge packages are available.

Are we OK to start merging now?

Yep, it's fine now. Not sure if I was clear, but it was only backporting to 2.0.x which was a problem. It's fine now, but as expected just for things that should go into the final 2.0.0 release.

Comment From: WillAyd

Just to note, these unclosed files are from matplotlib and not related to us #44844 (comment)

The Python standard documentation has an explicit example of using tracemalloc to hunt these down. Stumbled across this and never personally used it, but might help someone with a passion for troubleshooting this one

https://docs.python.org/3/library/devmode.html#resourcewarning-example

Comment From: datapythonista

ppc64 still failing in conda forge, moving forward with the rest

Comment From: datapythonista

All conda-forge packages published (except ppc64), and release announced.

Unless there is something unexpected with the second release candidate, the plan is to release the final 2.0.0 in around two weeks.

We should do something with ppc64 before that. If the problem isn't easy to fix, should we xfail the date mismatches for that architecture, or should we remove ppc64 from conda-forge builds? No strong preference from my side.

Comment From: MarcoGorelli

there's quite a few issues / PRs with the 2.0 milestone

it's hard to tell which are blockers - I'm trying to remove ones which clearly aren't blockers, but for others, could people please check whether the milestone of their issues/PRs should be updated?

Comment From: phofl

Thoughts on releasing later this week or early next week?

Comment From: MarcoGorelli

are your open PRs milestoned to 2.0 not blockers? if so, let's do it!

probably best over the weekend or on monday, or avoid breaking code on a thursday/friday

Comment From: phofl

The ones that should get in are ready, the others are not blockers, should have cleared this out by tomorrow (hopefully)

Comment From: datapythonista

I'm busy this week, but I should be able to release on Monday of everything is ready. One thing that we should fix if it hasn't been addressed is the ppc64 builds. We can skip the tests for that platform if we're happy to release with the bug with wrong dates on that platform. Or we can decide to not support ppc64 and remove the wheela jobs too.

@jbrockmendel could you have a look at the problem?

Comment From: jbrockmendel

Sure, is there a link?

Comment From: datapythonista

Sure, is there a link?

I don't think we created an issue, and the log is gone now, but I opened a PR to regenerate it. You should have the failures in like 3 hours: https://github.com/conda-forge/pandas-feedstock/pull/158

Comment From: datapythonista

Starting the release. Please do not merged things with the 2.0 milestone (I rolled the milestone of outstanding issues/PRs), and do not tag things to that milestone.

You can continue merging to main as usual.

Comment From: datapythonista

I created the 2.0.1 milestone, which is backporting to the 2.0.x branch. Feel free to add any regression issue (or anything worth backporting, but as with the 2.0 milestone, please do not merge issues with that milestone before the release is ready (it's not a big deal, but adds a bit of confusion if things are added to the 2.0.x branch at this point).

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

Comment From: datapythonista

Tag created and pushed

Comment From: MarcoGorelli

awesome! thanks a tonne for doing this

OK to merge to 2.0.x (e.g. backporting docs corrections)?

Comment From: datapythonista

OK to merge to 2.0.x (e.g. backporting docs corrections)?

Yes, I don't think merging to 2.0.x should cause any problem with the release now.

Comment From: datapythonista

GitHub release created: https://github.com/pandas-dev/pandas/releases/tag/v2.0.0

Comment From: datapythonista

Seems like we added tzdata to the dependencies since the RC, the conda-forge builds have failed. I'll add the dependency there, and rerun.

Comment From: datapythonista

pip packages are now ready: https://pypi.org/project/pandas/#history

Looks like simply adding the tzdata dependency didn't fix the conda-forge problem, I'm trying to understand what's going on, it's not immediately clear to me.

Comment From: datapythonista

The problem with tzdata is fixed. We had the same ppc errors we had for the RCs, and also a failure in one of the windows builds that hopefully has been something temporary and is fixed after reattempting.

Besides that, seems like there is an issue with conda-forge: https://github.com/conda-forge/status/issues/143

It starts to be late in my timezone, but if someone wants to have a look at the feedstock PR in couple of hours, and if both the windows failure and the conda-forge problem are fixed, feel free to merge. Otherwise I'll continue with this tomorrow morning UAE time.

Comment From: datapythonista

All good now with conda-forge, PR merged, packages should be available in one or two hours for most architectures: https://github.com/conda-forge/pandas-feedstock/pull/159

Comment From: datapythonista

Most packages for conda-forge are already available, and many others should be available soon: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=683592&view=results

I'm going to announce the release now.

Comment From: datapythonista

Release complete (pending few conda-forge ARM builds) and announced. Closing this, issue for the 2.0.1 release: https://github.com/pandas-dev/pandas/issues/52383.

Pandas RLS: 2.0

Blockers

Scheduled

References

51871 is the last one that should go into the rc. I hope that this is ready now so we should be able to cut the rc soonish