DOC: Add whatsnew for 2.3.0
- [ ] closes #xxxx (Replace xxxx with the GitHub issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Is the plan to eventually change this into a 3.0 whatsnew if we don't release a 2.3? I think this is the plan, yes. I think we should move to 3.0 immediately after the actual release is out this time, enforcing the deprecations will take some time. > Is the plan to eventually change this into a 3.0 whatsnew if we don't release a 2.3?

Yep. I only tagged 2.3 since I think Patrick/Joris were thinking about a 2.3 release that changing chained assignment warnings from DeprecationWarnings to FutureWarnings.

In the case that 2.3 doesn't happen, it's pretty easy to re-tag/rename the whatsnew.
(we did this last time with the 1.6.0.dev0 tag)

> I think this is the plan, yes. I think we should move to 3.0 immediately after the actual release is out this time, enforcing the deprecations will take some time.

I think we should hold off on the deprecation/API breaking PRs for now, so we can discuss more amongst the core team about whether the next release after 2.2 should be 2.3/3.0.

We can also take a little more time for 3.0 just to make sure that everything is done right. > Yep. I only tagged 2.3 since I think Patrick/Joris were thinking about a 2.3 release that changing chained assignment warnings from DeprecationWarnings to FutureWarnings.

That wouldn't be from main but rather from 2.2.x, we both agreed that we wouldn't want to do a regular 2.3 release if we want to do one at all. I am leaning towards to starting with a FutureWarning now anyway

> I think we should hold off on the deprecation/API breaking PRs for now, so we can discuss more amongst the core team about whether the next release after 2.2 should be 2.3/3.0.

I don't see any need for a new discussion about this, we agreed to to 2.2 -> 3.0 and nothing changed since then /nothing blocking was brought up on the 2.2 issue

> We can also take a little more time for 3.0 just to make sure that everything is done right.

I agree that we should do this if it becomes necessary, but we shouldn't plan for this now. 2.0 was pushed off and that was not great for any of us. > That wouldn't be from main but rather from 2.2.x, we both agreed that we wouldn't want to do a regular 2.3 release if we want to do one at all. I am leaning towards to starting with a FutureWarning now anyway

+1 to this. It becomes really difficult to backport to and release from a release branch(e.g. 2.2.x) towards the end of the release cycle for a branch.

(I will probably keep the file named as-is for now, and rename when I tag 3.0.0dev0)

> I don't see any need for a new discussion about this, we agreed to to 2.2 -> 3.0 and nothing changed since then /nothing blocking was brought up on the 2.2 issue

Sure, but I still don't think we should instantly start merging deprecation/API breaking PRs regardless.

Looking really quickly, we have at least 3 "controversial" deprecations that we need to decide if we want to revert or not:
#53491 ,#56226, #56422

We should close those out first, before doing any deprecation enforcement/API breaks. Yeah I agree with the deprecations, but those should happen before the actual release anyway imo Going to self-merge for now to get this in.