ENH: New proposed deprecation policy
xref #54970

Use `DeprecationWarning` until the last minor version before a major release then we switch to `FutureWarning`
One thing to note is that when using `pytest.mark.filterwarnings` I have kept the ignore string as `"ignore::DeprecationWarning"` which we will need to change to `FutureWarning` once we change `Pandas40DeprecationWarning`, my reasoning for this is that you have to pass the module path (so `ignore::pandas.util._exceptions.Pandas40DeprecationWarning`) for aliased warnings, which didn't look pretty to me This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this. Gentle ping @lithomas1. I would like this to move forward so I don't have to update it every time a new deprecation is added > Gentle ping @lithomas1. I would like this to move forward so I don't have to update it every time a new deprecation is added

Thanks for the reminder (and sorry that this slipped off my radar).
Will take a look this evening. One thing we also could consider doing is decoupling the test changes from this PR, and just introducing ``Pandas40DeprecationWarning``, and basic tests that it works as expected.

That way there's less chances of this creating conflicts and getting out of sync. I think switching to Future warning only one release before the release that will break is too short.  My motion on this is that it would be only 6 months or so, and sometimes less.  Often end users report issues to projects through future warnings. This then requires downstream to make the changes and make a release before the next pandas, or face a break (unless strictly capping, which is not common). 

Producing a FutureWarning 2 releases prior to breaking things seems like a more balanced approach.   > Producing a FutureWarning 2 releases prior to breaking things seems like a more balanced approach.

That would mean any deprecations released in the last 2 minor releases will immediately be FutureWarnings which means downstream libraries won't have *any* time to handle/suppress these warnings. Had we implemented your idea earlier, v2.1 deprecations would immediately be FutureWarning (there are a lot of them, see #50578), one of them being the cause of #54970 being opened in the first place.

I guess if we think some deprecation needs attention by end users, we can leave it as a FutureWarning and postpone enforcing the deprecation to a later major release. @Aloqeely we had a discussion about our deprecation policy at the bi-weekly developers meeting, and we think that a PDEP should be created that would formalize the policy and allow for greater discussion.  Are you willing to write up a PDEP with a proposed policy? Sure, I can give it a go.
Going to close this for now