Use 2.0.0 in Airflow docs & Breeze (apache#13379)

BREEZE.rst

@@ -801,7 +801,7 @@ Generating constraints
 ----------------------
 
 Whenever setup.py gets modified, the CI master job will re-generate constraint files. Those constraint
-files are stored in separated orphan branches: ``constraints-master`` and ``constraint-1-10``.
+files are stored in separated orphan branches: ``constraints-master``, ``constraints-2-0`` and ``constraints-1-10``.
 They are stored separately for each python version. Those are
 constraint files as described in detail in the
 `<CONTRIBUTING.rst#pinned-constraint-files>`_ contributing documentation.
@@ -1283,7 +1283,7 @@ This is the current syntax for  `./breeze <./breeze>`_:
           If specified, installs Airflow directly from PIP released version. This happens at
           image building time in production image and at container entering time for CI image. One of:
 
-                 1.10.14 1.10.12 1.10.11 1.10.10 1.10.9 none wheel sdist
+                 2.0.0 1.10.14 1.10.12 1.10.11 1.10.10 1.10.9 none wheel sdist
 
           When 'none' is used, you can install airflow from local packages. When building image,
           airflow package should be added to 'docker-context-files' and
@@ -1538,11 +1538,11 @@ This is the current syntax for  `./breeze <./breeze>`_:
 
         Generates pinned constraint files from setup.py. Those files are generated in files folder
         - separate files for different python version. Those constraint files when pushed to orphan
-        constraint-master and constraint-1-10 branches are used to generate repeatable
-        CI builds as well as run repeatable production image builds. You can use those constraints
-        to predictably install released Airflow versions. This is mainly used to test the constraint
-        generation - constraints are pushed to the orphan branches by a successful scheduled
-        CRON job in CI automatically.
+        constraints-master, constraints-2-0 and constraints-1-10 branches are used to generate
+        repeatable CI builds as well as run repeatable production image builds. You can use those
+        constraints to predictably install released Airflow versions. This is mainly used to test
+        the constraint generation - constraints are pushed to the orphan branches by a
+        successful scheduled CRON job in CI automatically.
 
   Flags:
 
@@ -2389,7 +2389,7 @@ This is the current syntax for  `./breeze <./breeze>`_:
           If specified, installs Airflow directly from PIP released version. This happens at
           image building time in production image and at container entering time for CI image. One of:
 
-                 1.10.14 1.10.12 1.10.11 1.10.10 1.10.9 none wheel sdist
+                 2.0.0 1.10.14 1.10.12 1.10.11 1.10.10 1.10.9 none wheel sdist
 
           When 'none' is used, you can install airflow from local packages. When building image,
           airflow package should be added to 'docker-context-files' and

CONTRIBUTING.rst

@@ -756,7 +756,7 @@ when installing ``apache-airflow``, you might need to provide additional constra
 example ``pip install apache-airflow==1.10.2 Werkzeug<1.0.0``)
 
 However we now have ``constraints-<PYTHON_MAJOR_MINOR_VERSION>.txt`` files generated
-automatically and committed to orphan ``constraints-master`` and ``constraint-1-10`` branches based on
+automatically and committed to orphan ``constraints-master``, ``constraints-2-0` and ``constraints-1-10`` branches based on
 the set of all latest working and tested dependency versions. Those
 ``constraints-<PYTHON_MAJOR_MINOR_VERSION>.txt`` files can be used as
 constraints file when installing Apache Airflow - either from the sources:

README.md

@@ -133,7 +133,7 @@ produce unusable Airflow installation.
 
 In order to have repeatable installation, however, introduced in **Airflow 1.10.10** and updated in
 **Airflow 1.10.12** we also keep a set of "known-to-be-working" constraint files in the
-orphan `constraints-master` and `constraints-1-10` branches. We keep those "known-to-be-working"
+orphan `constraints-master`, `constraints-2-0` and `constraints-1-10` branches. We keep those "known-to-be-working"
 constraints files separately per major/minor python version.
 You can use them as constraint files when installing Airflow from PyPI. Note that you have to specify
 correct Airflow tag/version/branch and python versions in the URL.
@@ -150,15 +150,15 @@ of extras. In order to install Airflow you need to either downgrade pip to versi
 
 
 ```bash
-pip install apache-airflow==1.10.14 \
- --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-1.10.14/constraints-3.7.txt"
+pip install apache-airflow==2.0.0 \
+ --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.0.0/constraints-3.7.txt"
 ```
 
 2. Installing with extras (for example postgres,google)
 
 ```bash
-pip install apache-airflow[postgres,google]==1.10.14 \
- --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-1.10.14/constraints-3.7.txt"
+pip install apache-airflow[postgres,google]==2.0.0 \
+ --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.0.0/constraints-3.7.txt"
 ```
 
 For information on installing backport providers check [/docs/backport-providers.rst][/docs/backport-providers.rst].

breeze

@@ -1707,11 +1707,11 @@ ${CMDNAME} generate-constraints [FLAGS]
 
       Generates pinned constraint files from setup.py. Those files are generated in files folder
       - separate files for different python version. Those constraint files when pushed to orphan
-      constraint-master and constraint-1-10 branches are used to generate repeatable
-      CI builds as well as run repeatable production image builds. You can use those constraints
-      to predictably install released Airflow versions. This is mainly used to test the constraint
-      generation - constraints are pushed to the orphan branches by a successful scheduled
-      CRON job in CI automatically.
+      constraints-master, constraints-2-0 and constraints-1-10 branches are used to generate
+      repeatable CI builds as well as run repeatable production image builds. You can use those
+      constraints to predictably install released Airflow versions. This is mainly used to test
+      the constraint generation - constraints are pushed to the orphan branches by a
+      successful scheduled CRON job in CI automatically.
 
 Flags:
 $(breeze::flag_airflow_variants)

breeze-complete

@@ -51,6 +51,7 @@ _breeze_allowed_package_formats="wheel sdist both"
 }
 
 _breeze_allowed_install_airflow_versions=$(cat <<-EOF
+2.0.0
 1.10.14
 1.10.12
 1.10.11

docs/apache-airflow/installation.rst

@@ -33,7 +33,7 @@ not work or will produce unusable Airflow installation.
 
 In order to have repeatable installation, however, starting from **Airflow 1.10.10** and updated in
 **Airflow 1.10.13** we also keep a set of "known-to-be-working" constraint files in the
-``constraints-master`` and ``constraints-1-10`` orphan branches.
+``constraints-master``, ``constraints-2-0`` and ``constraints-1-10`` orphan branches.
 Those "known-to-be-working" constraints are per major/minor python version. You can use them as constraint
 files when installing Airflow from PyPI. Note that you have to specify correct Airflow version
 and python versions in the URL.
@@ -61,14 +61,14 @@ and python versions in the URL.
 
 .. code-block:: bash
 
-    AIRFLOW_VERSION=1.10.14
+    AIRFLOW_VERSION=2.0.0
     PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)"
     # For example: 3.6
     CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"
-    # For example: https://raw.githubusercontent.com/apache/airflow/constraints-1.10.14/constraints-3.6.txt
+    # For example: https://raw.githubusercontent.com/apache/airflow/constraints-2.0.0/constraints-3.6.txt
     pip install "apache-airflow==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"
 
-    Please note that with respect to Python 3 support, Airflow 1.10.14 has been
+    Please note that with respect to Python 3 support, Airflow 2.0.0 has been
     tested with Python 3.6, 3.7, and 3.8, but does not yet support Python 3.9.
 
 2. Installing with extras (for example postgres, google)
@@ -84,7 +84,7 @@ and python versions in the URL.
 
 .. code-block:: bash
 
-    AIRFLOW_VERSION=1.10.14
+    AIRFLOW_VERSION=2.0.0
     PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)"
     CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"
     pip install "apache-airflow[postgres,google]==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"
@@ -102,8 +102,8 @@ As of Airflow 2.0 we agreed to certain rules we follow for Python support. They
 release schedule of Python, nicely summarized in the
 `Python Developer's Guide <https://devguide.python.org/#status-of-python-branches>`_
 
-1. We finish support for python versions when they reach EOL (For python 3.6 it means that we will remove it
-   from being supported on 23.12.2021).
+1. We end support for Python versions when they reach EOL (For Python 3.6 it means that we will stop supporting it
+   on 23.12.2021).
 
 2. The "oldest" supported version of Python is the default one. "Default" is only meaningful in terms of
    "smoke tests" in CI PRs which are run using this default version.