Add Python version support contribution skill

[Dev-iL]

related:

• Python 3.14 Support #63520
• Drop Python 3.10 support #74148

This PR distills the above into a skill to facilitate future addition and removal of python version support from core/sdk/providers. The plan is to make use of this in the upcoming addition of python 3.15 support.

Although we add or remove a python version from core only once a year each, I believe this is worth a skill for the provider coverage part of it, because it helps the user identify problematic providers so they can be disabled (skill-assistedly) and their maintainers reached out to.

TODO: deal with free-threaded python versions.

---

AI Summary

Python version changes span package metadata, dependency compatibility, CI, images, tooling, and documentation. Missing one of these surfaces can leave support incomplete and require follow-up PRs. Add a python-version-support skill with self-contained workflows for adding a version, retiring a version, and excluding or enabling individual providers on an already supported interpreter.

The skill plans repository-wide changes as GitHub PR stacks, with guidance for native stack review and single-PR or manually managed contributions from forks. It strongly recommends landing retirement before starting a separate addition effort. Shared guidance covers version-policy centralization across the monorepo; historical PRs are optional references at the ends of the guides.

The addition workflow begins with a dependency-readiness preflight. It investigates direct and transitive blockers in isolated, target-specific scratch projects, preserves uv diagnostics, and tracks upstream releases, issues, and proposed fixes. A standard-library helper captures immutable attempts and renders a deterministic component table. Diagnostic exclusions, overrides, altered requirements, operational failures, and incomplete checks remain visibly non-ready. Provider-only amendments reuse this preflight within their affected scope.

Includes Claude and GitHub skill-discovery symlinks and the corresponding ignore rules. Restricts the agentic Markdown license hook to Markdown so bundled Python scripts receive only the standard Python license header. No Airflow runtime support metadata or dependencies are changed.

Validation:

• 24 focused tests passed in Python 3.14 Breeze, including offline uv failure/exclusion probes, deterministic reports, incomplete coverage, input snapshots, and configuration guards.
• Ruff formatting and lint checks passed.
• Skill validation and staged whitespace checks passed.
• All applicable pre-commit and commit-message hooks passed.

Current Python 3.15 dependency readiness report

Measured on 2026-10-07 using Python 3.15.0rc2 and uv 0.12.13 in Breeze, against checkout f4c351dac4329a5dc64c995b2502a95b67f91549. Covers core, SDK, CLI, 109 providers, and the combined graph on Linux amd64 and arm64.

All 226 declared-runtime uv lock checks passed. Six additional checks explicitly requested dependencies omitted by existing Python markers: Ray failed on both architectures. Scratch-only exclusion retries then resolved the reduced graphs; the Ray profiles remain ❌. In total, 234 uv lock attempts were captured across 232 planned checks. The existing OpenAI override was retained where relevant and flagged for review.

The summarized table below includes unresolved wheel/build and marker evidence, beyond resolver-only success. ❌ does not establish that source builds fail: those remain untested. The Linux wheel baseline is CPython with the GIL and glibc 2.36.

Component	Ready	Dependency details
core	❌	Runtime lock passed on both architectures. Selected httptools==0.8.0, lazy-object-proxy==1.12.0, pydantic-core==2.46.5, and PyYAML==6.0.3 have 3.14 wheels but no matching 3.15 wheels; source builds remain untested.
sdk	❌	Runtime lock passed; inherits the four core wheel/build gaps through its core dependency.
provider-apache.cassandra	❌	Existing markers omit cassandra-driver on 3.15. Explicit driver resolution succeeds via an sdist, but latest 3.30.1 has no matching cp315 wheels.
provider-google	❌	Existing markers omit Ray on 3.15. Explicit ray[default]>=2.55.0 fails uv lock on both architectures because matching cp315 wheels are unavailable.
provider-snowflake	❌	Existing markers omit Snowpark. Explicit resolution succeeds, but latest snowflake-snowpark-python==1.55.1 declares Requires-Python <3.15.
aggregate	❌	Declared runtime lock passed with the existing OpenAI override. Selected candidates have 42 wheel gaps on amd64 and 41 on arm64, including pre-existing source-only packages.

The report preserves exact dependency candidates, ownership/paths, architecture-specific wheel inventories, raw uv diagnostics, input snapshots, and published metadata comparisons. Verified upstream tracking includes Ray #61200, PyYAML PR #963, Arrow #50091, and pyodbc #1506. No upstream messages were posted. This preflight does not validate source builds, installation, runtime tests, development groups, other optional extras, or image builds.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Codex (GPT-6.1 Sol) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.