DOC: Add whatsnew for 2.3.0

[lithomas1]

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations 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.

[mroeschke]

Is the plan to eventually change this into a 3.0 whatsnew if we don't release a 2.3?

[phofl]

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.

[lithomas1]

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.

[phofl]

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.

[lithomas1]

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.

[phofl]

Yeah I agree with the deprecations, but those should happen before the actual release anyway imo

[lithomas1]

Going to self-merge for now to get this in.