Fail PR when common compat changes and there is no # use next version

[potiuk]

When common.compat changes, but the providers that use it, do not have # use next version added for the common-compat dependency, the PR should fail.

You can still bypass the check with the label set on the PR:

'skip common compat check'

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

This is an error that will be printed on PR when common.compat changes and other providers are changing in the same PR but there is no # use next version added;

You can test it with breeze ci selective-check --commit-ref c52606a7a7465f5900f16bb8719c6d378c320df5

[potiuk]

cc: @ephraimbuddy :) -> this way in the future, the one who modifies common.compat will not be able to merge their PR until # use next version is added.

[jscheffl]

A lot of AI generated code that is very verbose. Sometimes I think the AI bot is paid by LoC generated and not by making it conceise.

[potiuk]

A lot of AI generated code that is very verbose. Sometimes I think the AI bot is paid by LoC generated and not by making it conceise.

Yeah. I did it late in night and after waking up, it was a bit too verbose. I asked Claude Sonnet to simplify and it not only did all the changes you suggested but also nicely refactored it into separate private methods which IMHO makes it far easier to comprehend and understand what we are doing

[potiuk]

A lot of AI generated code that is very verbose. Sometimes I think the AI bot is paid by LoC generated and not by making it conceise.

Not in this case, but in a way that might be a good thing. More verbose code is quite often easier to understand - even if longer to read. Sometimes the comprehensions take quite a bit of mental effort to understand where simple for loop is clear and straightforrward. I think human authors (comparing to AI) over-optimise for "writing" rather than "reading" - and writing concise and short code is preferred by some people, but it only works to a point.

But yes. This one was definitely too chatty.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 65aec2d v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue