pandas-dev
RLS: 2.0
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 on pandas 2)
currently scheduled for December 31, 2022
https://github.com/pandas-dev/pandas/milestone/42
master tracker for API: Breaking Changes in 2.0 (without deprecations) #44823
It was noted in the dev meeting that we don't have a master tracker for deprecations that should be in a released pandas before we release 2.0. Feel free to mention those here or in #45223. There are also some mentioned in https://github.com/pandas-dev/pandas/issues/41957#issuecomment-998325370) but note that if all the desired deprecations are not done, we may decide to not block the 1.5 release and then the next release would be 1.6 to allow time for further deprecations to be included.
cc @pandas-dev/pandas-core @pandas-dev/pandas-triage
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.
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
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.
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
@pandas-dev/pandas-core Are there any objections for the next release to be 2.0?
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
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.
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.
Updated the issue description after the outcome of the 2023-01-11 dev meeting (only blocker was the Int/Uint/FloatIndex removal)
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
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.
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?
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.
It'd be good to get in #51335 for a few reasons (see the linked issues), but not a blocker in my opinion.
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.
Wheel builders are currently broken on Windows and uploads don't work on aarch. Can you give till Monday to work things out?
I have a PR open for aarch uploads but it'll take until the next nightly to verify it works.
Absolutely, I didn't see that, thanks for the heads up. Let's aim next week then, let me know if you need help.
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.
@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
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).
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.
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)
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?
Maybe 1.5.4?
Ideally, cibuildwheel should be able to handle tags on any branch, so hopefully it's not necessary.
@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?