ENH: New proposed deprecation policy

[Aloqeely]

xref #54970

Use DeprecationWarning until the last minor version before a major release then we switch to FutureWarning

[Aloqeely]

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

[github-actions[bot]]

This pull request is stale because it has been open for thirty days with no activity. Please update and respond to this comment if you're still interested in working on this.

[Aloqeely]

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

[lithomas1]

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.

[lithomas1]

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.

[bashtage]

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.

[Aloqeely]

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.

[Dr-Irv]

@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?

[Aloqeely]

Sure, I can give it a go. Going to close this for now