1fanwang opened a new pull request, #71159: URL: https://github.com/apache/airflow/pull/71159
A provider config option's `version_added` is a guess. The contributor has no way to know which release will carry the change, so they write the next version number. If a release is cut while the PR is in review the guess is wrong, and nothing revalidates it: the schema types the field as a nullable string, and no check compares it to anything. It is not cosmetic. `conf_constants.py` drops options whose `version_added` is newer than the package being documented, so a wrong value defeats the filter that keeps new options off old version pages. `cncf-kubernetes` 10.21.0rc1 ships two options declaring `version_added: 10.20.0`, corrected in https://github.com/apache/airflow/pull/71157. Running the same comparison over the last five releases of every provider found two more, from unrelated PRs: 13 `apache.kafka` options declaring 1.14.1, which was never released, and `openlineage.emission_policy` declaring 2.18.0 when it first appears in 2.19.0. ### Why release preparation, not a pre-commit hook A PR-time check cannot catch this. Branches are not required to be up to date before merge, so it passes against a base that predates the release and never runs again. The `cncf-kubernetes` PR's last commit was 2026-07-22, the 10.20.0 release commit landed 2026-07-23, and it merged on 2026-07-29 without a rebase. A hook would have compared against `versions[0]: 10.19.0` and gone green. Release preparation knows the version being released, and runs on the merged tree. ### What this does In `_update_version_in_provider_yaml`, read the previous release's `provider.yaml` from its git tag and compare the config option sets. Anything new since that release must declare the version being prepared. Only options introduced since the last release are examined, so a value that already shipped wrong is never re-flagged and no release is blocked retroactively. A null is left alone, since the schema permits it. A missing tag, which happens on a first release or when a provider's path moves, skips the check rather than failing it. related: https://github.com/apache/airflow/pull/71157 ### Testing Driven through the real `_verify_version_added_fields`, against the real repository, with no mocks. <details> <summary>Raw logs</summary> Red, on `main` as it stands today, preparing 10.21.0 from 10.20.0: ``` $ python /tmp/e2e_va.py AIRFLOW_ROOT_PATH = /private/tmp/airflow-va-check Wrong version_added in /private/tmp/airflow-va-check/providers/cncf/kubernetes/provider.yaml. These options do not exist in 10.20.0, so they first ship in 10.21.0: kubernetes_executor.async_pod_creation: has 10.20.0, expected 10.21.0 kubernetes_executor.pod_creation_max_concurrency: has 10.20.0, expected 10.21.0 RESULT: breeze exited with code 1 exit=1 ``` Green, with the fix from https://github.com/apache/airflow/pull/71157 applied: ``` $ git apply version_added_fix.patch $ python /tmp/e2e_va.py AIRFLOW_ROOT_PATH = /private/tmp/airflow-va-check RESULT: passed (no wrong version_added) RESULT: breeze exited with code 0 exit=0 ``` The same comparison over the last five releases of every provider, to measure false positives: ``` provider/version pairs checked: 444 skipped (no tag/unreadable): 56 pairs flagged: 2 apache.kafka: 1.14.0 -> 1.15.0 kafka_event_producer.dag_run_events_enabled version_added=1.14.1 kafka_event_producer.task_instance_events_enabled version_added=1.14.1 kafka_event_producer.kafka_config_id version_added=1.14.1 kafka_event_producer.topic version_added=1.14.1 kafka_event_producer.source version_added=1.14.1 kafka_event_producer.dag_run_dag_id_allowlist version_added=1.14.1 kafka_event_producer.dag_run_dag_id_denylist version_added=1.14.1 kafka_event_producer.task_instance_dag_id_allowlist version_added=1.14.1 kafka_event_producer.task_instance_dag_id_denylist version_added=1.14.1 kafka_event_producer.task_instance_task_id_allowlist version_added=1.14.1 kafka_event_producer.task_instance_task_id_denylist version_added=1.14.1 kafka_event_producer.topic_check_timeout version_added=1.14.1 kafka_event_producer.topic_check_retry_interval version_added=1.14.1 openlineage: 2.18.1 -> 2.19.0 openlineage.emission_policy version_added=2.18.0 ``` Both verified by hand. `providers-apache-kafka/1.14.1` does not exist and the versions list goes 1.14.0 to 1.15.0. `emission_policy` has zero occurrences in the 2.18.0 and 2.18.1 tags and one in 2.19.0. A wrong value is reported once, at the release that introduces the option, and never again: ``` -- cncf.kubernetes: preparing 10.21.0 from 10.20.0 (option is new) -- ERROR: kubernetes_executor.async_pod_creation has version_added: 10.20.0 but did not exist in 10.20.0; it first ships in 10.21.0 ERROR: kubernetes_executor.pod_creation_max_concurrency has version_added: 10.20.0 but did not exist in 10.20.0; it first ships in 10.21.0 -- cncf.kubernetes: preparing 10.22.0 from 10.21.0rc1 (option already shipped) -- OK: every option new since 10.21.0rc1 declares 10.22.0 ``` Unit tests: ``` $ pytest tests/test_provider_documentation.py -q 67 passed in 0.22s ``` </details> --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes (please specify the tool below) Generated-by: GitHub Copilot CLI following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
