Shahar EpsteinandJarek Potiuk
9cc55f2ad3
* Update docs for the Python 3.11 baseline Contributing docs, Breeze docs, Docker stack docs and the user-facing installation pages used Python 3.10 as the example and default version. Examples and defaults now use 3.11; historical changelog entries and ADRs keep their original wording. * Re-pad the image naming table after dropping Python 3.10 * Fix stale Python 3.10 examples left in the Python 3.11 docs update Review found commands that still pin a 3.10.x interpreter, which can no longer install Breeze or Airflow, shell prompts and pytest transcripts that still show 3.10, and a note that tied the supported Python range to Airflow 3.2.0 even though the 3.2 to 3.4 release lines still accept 3.10. Two Breeze examples used options that do not exist. The python-client release notes presented `breeze --python 3.11` as equivalent to `UV_PYTHON=3.11`, but the reproducibility guard checks the interpreter Breeze itself runs on, so only the `UV_PYTHON` form works. The Docker stack build examples now refer to the default Python version instead of a hard-coded one, so they stop drifting with every bump. * Fix remaining Python 3.10 references in docs and image examples Review found more shell prompts that still show a 3.10 Breeze image. The air-gapped image example pinned Airflow 2.5.3, which publishes no 3.11 constraints, so its download step fetched a 404 page and failed; it also used extras that Airflow 3 no longer defines. The contributor quick start called 3.10 end-of-life before its October 2026 end-of-life date. * Update Python version in database setup guide Updated Python version in setup instructions from 3.8.10 to 3.11.16. * Fix stale Python 3.10 constraints examples in INSTALL Generated-by: Claude Opus 5 --------- Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
Sometimes you might want to update dependencies of airflow in bulk, when working on related set of
packages/dependencies. This might lead to excessive time needed to rebuild the image with new versions
of dependencies (due to pip backtracking) and necessity to rebuild the image multiple times
and solving conflicting dependencies.
For development use only, you can store your own version of constraint files used during CI image build
here and refer to them during building of the image using --airflow-constraints-location constraints/constraints.txt
This allows you to iterate on dependencies without having to run --upgrade-to-newer-dependencies flag continuously.
Typical workflow in this case is:
- download and copy the constraint file to the folder (for example via The GitHub Raw Link)
- modify the constraint file in "constraints" folder
- build the image using this command
breeze ci-image build --python 3.11 --airflow-constraints-location constraints/constraints-3.11.txt
You can continue iterating and updating the constraint file (and rebuilding the image) while iterating, you can also manually add/update the dependencies and after you are done, you can regenerate the set of constraints based on your currently installed packages, using this command:
pip freeze | sort | \
grep -v "apache_airflow" | \
grep -v "apache-airflow==" | \
grep -v "@" | \
grep -v "/opt/airflow" > /opt/airflow/constraints/constraints-3.11.txt
If you are working with others on updating the dependencies, you can also commit the constraint file to the repository and then anyone else working on the same branch/fork, can use it for local image building (but the file should be removed before the branch you are working on is merged to the main branch).