Change check_freq default to False

[MaxWinterstein]

• closes Change the default of check_freq to False as it breaks existing code #35570
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

[jbrockmendel]

This effectively disables a bunch of existing checks. passing check_freq=True explicitly in a ton of places is an option i guess. or could change the default to False and warn that it will become True in a future version

[jreback]

we need to leave this as true as its more strict; sure it might have broken downstream, but not testing things is not great, so -1 on this PR

[TomAugspurger]

And FYI, this came up on the dev call on Wednesday. The consensus was roughly "we didn't mean to change this for 1.1.0, but now that we have it's best to just leave it."

Apologies for the accidental breaking change @MaxWinterstein, and thanks for working on the PR but we'll pass.

In the future, you might want to subscribe to pandas releases by "watching" the repo for "releases only". We make binaries available for release candidates so it should be easy to test.

[MaxWinterstein]

And FYI, this came up on the dev call on Wednesday. The consensus was roughly "we didn't mean to change this for 1.1.0, but now that we have it's best to just leave it."

Apologies for the accidental breaking change @MaxWinterstein, and thanks for working on the PR but we'll pass.

In the future, you might want to subscribe to pandas releases by "watching" the repo for "releases only". We make binaries available for release candidates so it should be easy to test.

First of all, i am totally fine by keeping it that way. No hate.

I was/am just a little unhappy that this is - in my opinion - a bigger change that should be mentioned in the change logs anywhere. But afaik there is no mention at all.
As our automated tests on ou rCI failed successfully, there was no hassle or problem on production side, as we keep requirements versioned (as everybody should 😉 ). But when you try to update your requirements and you need to dig inside the projects to find why something is suddenly broken, its a little bit frustrating...

[TomAugspurger]

For sure. This was a process failure where we merged a breaking API change to master. That was noticed during review, but a followup issue was never opened.

As I mentioned in the issue, updating the release notes to explain this API change may still be worthwhile since it might help future upgraders.