shahar1 commented on code in PR #74151:
URL: https://github.com/apache/airflow/pull/74151#discussion_r4173412968


##########
dev/refresh_images.sh:
##########
@@ -26,7 +26,7 @@ export PLATFORM=${PLATFORM:="linux/amd64,linux/arm64"}
 
 breeze setup self-upgrade --use-current-airflow-sources
 
-for PYTHON in 3.10 3.11 3.12 3.13
+for PYTHON in 3.11 3.12 3.13 3.14

Review Comment:
   Looks like an oversight rather than a deliberate choice. The Python 3.13 
support PR (#46891) added 3.13 to both loops in this script. The Python 3.14 
support PR (#63520) did not touch the script at all, and nothing in it explains 
skipping 3.14.
   
   The script is the manual, committer-only way to refresh the CI image cache 
(see `dev/MANUALLY_GENERATING_IMAGE_CACHE_AND_CONSTRAINTS.md`). Leaving out a 
supported version only means its cache is never refreshed by hand. So this PR 
makes both loops match the supported list, `3.11 3.12 3.13 3.14`.
   
   ---
   Drafted-by: Claude Code (Opus 5.5) (no human review before posting)



##########
scripts/ci/prek/update_docker_gpg_keys.py:
##########
@@ -41,8 +41,6 @@
     "postgres": "7FCC7D46ACCC4CF8",
     # Microsoft APT repository signing key (MSSQL ODBC)
     "microsoft": "EB3E94ADBE1229CF",
-    # Python 3.10 release manager (Pablo Galindo Salgado)
-    "python-3.10": "A035C8C19219BA821ECEA86B64E628F8D684696D",

Review Comment:
   No equivalent is needed for 3.11. On `main`, `install_os_dependencies.sh` 
already verifies every Python from 3.11 up with Sigstore (`cosign verify-blob`, 
PEP 761). The identity and issuer maps for 3.11 to 3.14 are already in that 
branch. Only 3.10 took the PGP branch, and `python-3.10.asc` was the only 
Python key in `scripts/docker/keys/`.
   
   With 3.10 gone, the PGP branch and its key were dead code. This PR removes 
them and leaves the Sigstore path as the only one. The entry here only fed 
`scripts/docker/keys/python-3.10.asc`, so it goes too.
   
   ---
   Drafted-by: Claude Code (Opus 5.5) (no human review before posting)



##########
scripts/ci/testing/get_min_airflow_version_for_python.py:
##########
@@ -19,7 +19,7 @@
 import argparse
 
 MIN_AIRFLOW_VERSION_BY_PYTHON = {
-    "3.10": "2.11.0",
+    "3.11": "2.11.0",

Review Comment:
   Good catch, and it is a real gap, not just a mapping question. The only 
consumer is `.github/actions/migration_tests`. For each Python in the DB test 
matrix it installs this minimum version, migrates to heads, and runs "2 to 3" 
migration steps.
   
   - Today, 3.11 and 3.12 resolve to 2.11.0, so those jobs really test the 
Airflow 2 to Airflow 3 migration. 3.13 and 3.14 start from 3.1.0 and 3.2.0.
   - Once 3.12 is dropped, every matrix Python resolves to 3.1.0 or later. The 
script keeps working, because the lookup picks the highest key at or below the 
Python version. But the "2 to 3" steps silently become 3.x-to-heads tests, the 
`pydantic` extra branch becomes dead, and CI loses all 2.x-to-3 coverage.
   
   Python 3.12 is supported until October 2028, so this is not urgent. When it 
comes up, there are two options:
   
   1. Accept losing 2.x-to-3 coverage and rename the steps, if by then upgrades 
are expected to go through a 3.x release first.
   2. Keep coverage without a 2.11 runtime by seeding the DB from a committed 
2.11 schema dump per backend, then migrate to heads. The migration test only 
needs the 2.11 schema, not a running 2.11.
   
   Either way it is out of scope here: this PR only re-keys the 2.11 entry from 
3.10 to 3.11, since the lowest supported Python must have a key. I can open a 
tracking issue if you want it captured now.
   
   ---
   Drafted-by: Claude Code (Opus 5.5) (no human review before posting)



-- 
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]

Reply via email to