Skip to content

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

Open
5 tasks
mroeschke opened this issue Jun 6, 2025 · 2 comments
Open
5 tasks

RLS: 2.3.1 #61590

mroeschke opened this issue Jun 6, 2025 · 2 comments
Labels
Milestone

Comments

@mroeschke
Copy link
Member

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:

@simonjayhawkins
Copy link
Member

Thanks @mroeschke for opening this issue.

Placeholder issue if we decide to release 2.3.1.

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?

At the time of writing this issue, it's expected that pandas 3.0 would be the next version #57064

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 str.contains. It may not be relevant or too significant but our deprecation policy, PDEP-17 states:

Deprecated functionality should remain unchanged in at least 2 minor releases before being changed or removed
Deprecations should initially use DeprecationWarning, and then be switched to FutureWarning in the last minor release before the major release they are planned to be removed in

#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

@simonjayhawkins
Copy link
Member

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

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

2 participants