-
-
Notifications
You must be signed in to change notification settings - Fork 18.6k
RLS: 2.3.1 #61590
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
Comments
Thanks @mroeschke for opening this issue.
RLS 2.3 was driven by the need to release to the community for evaluation/experimentation the new np.nan variant of the nullable string dtype (both object fallback and pyarrow backed). So it would be, to me, a reasonable assumption that any issues reported regarding this new dtype would be fixed in the 2.3.x branch. Not providing these fixes to the community until the 3.0 release candidate would not allow time for proper evaluation/feedback? The new string dtype is behind a feature flag and experimental so changes to behavior could be added in a patch release? and not need to wait for a minor/major release? PDEP-14 states "The 2.3.0 release would then have all future string functionality available". Did all the issues related to the new dtype get into 2.3.0? I can see there are a few stale PRs for the string dtype that presumably still need to be resolved. These could be included in a patch release? So at this time i think it may be appropriate to assume that we will need to actively maintain the 2.3.x branch and that patch releases are more likely than not?
releasing 3.0 before an reasonable amount of time has elapsed would defeat the whole purpose and exercise of creating a 2.3 release. Some contributors have suggested a release cadence of 4 months between minor releases, but 6 months is probably more realistic? There is a deprecation in 2.3 related to
#59615 used a FutureWarning so we don't need to consider the 2nd clause. However, to honor the first clause may strictly require a 2.4 release before the behavior is then changed in 3.0? A pragmatic approach may be needed but also consideration to not making a mockery of the deprecation policy. Or just postpone enforcing that deprecation until 4.0. #59328 gives an overview of breaking changes |
There was consideration to including the breaking changes in the 2.3 release notes. This wasn't done in time for the 2.3 an hence the changes not yet communicated to the community. |
Placeholder issue if we decide to release 2.3.1. At the time of writing this issue, it's expected that pandas 3.0 would be the next version #57064
Notable tasks for 2.3.1:
pandas.__version__
is2.3.0+4.g1dfc98e16a
in pandas 2.3.0 and python 3.9, not2.3.0
#61579)The text was updated successfully, but these errors were encountered: