+1 on adding it to the release process. There is even a very good reason for it, which will become all but mandatory.
In the future, when we implement Internal API AIP (AIP-44) - if the user will want to use some airflow feature, they should be able to use the Python API client to communicate with Airflow - for anything that is not part of the "Internal API" (this is part of the AIP-44). Eventually we should pre-install the latest Python API client in our reference Airflow Docker Image as this should become the main way Dag Authors will want to interface with Airflow DB (Internal API is not intended to be used by DAG Authors but by internals of Airflow components). This implies that the docker Image is built after both "apache-airflow==X.Y.Z" and "apache-airflow-client==X.Y.z" are published in PyPI. Note "Airflow's Z" might be different from "Python client's z" - per our Python client versioning https://github.com/apache/airflow#semantic-versioning). There is not always a Python API client to release. There is always one when we release X.Y.0, but the subsequent ones might or might not happen (depending if there are fixes to the API/Client). J. On Mon, Nov 14, 2022 at 8:39 PM Jeambrun Pierre <[email protected]> wrote: > > Hi all, > > Hope you are doing well. > > Bringing this to your attention to discuss the release process of airflow api > clients. (Go and Python): > - https://github.com/apache/airflow-client-python > - https://github.com/apache/airflow-client-go > > At the moment clients versions are not synced with airflow versions. I > believe the release process for them is independent. For instance the latest > python client version available is 2.3.0. > > Should we make it part of our release process to also release api clients > when cutting new airflow core versions ? > > This question was raised here https://github.com/apache/airflow/pull/27642, > just in case you want to take a look. > > Best regards, > Pierre
