This is an automated email from the ASF dual-hosted git repository. ephraimanierobi pushed a commit to branch v2-8-test in repository https://gitbox.apache.org/repos/asf/airflow.git
commit 7642b29f5c0eaef898839579304ba0c8223801f1 Author: Jarek Potiuk <ja...@potiuk.com> AuthorDate: Mon Nov 20 23:59:16 2023 +0100 Update README.md to reflect changes we agreed to the versioning (#35764) There were two changes that we agreed and voted in the community that have not been properly reflected yet in README.md (they are reflected in detailed documentation though): * for providers, buping minimum version of Airflow is not a reason to bump MAJOR version - only MINOR * for API clients - they follow their own versioning SemVer scheme, independent from Airflow. --- README.md | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 294e52d81a..f68615dcd1 100644 --- a/README.md +++ b/README.md @@ -269,22 +269,15 @@ packages: they are present in providers as `install_requires` limitations. We aim to keep backwards compatibility of providers with all previously released Airflow 2 versions but there will sometimes be breaking changes that might make some, or all - providers, have minimum Airflow version specified. Change of that minimum supported Airflow version - is a breaking change for provider because installing the new provider might automatically - upgrade Airflow (which might be an undesired side effect of upgrading provider). + providers, have minimum Airflow version specified. * **Airflow Helm Chart**: SemVer rules apply to changes in the chart only. SemVer MAJOR and MINOR versions for the chart are independent of the Airflow version. We aim to keep backwards compatibility of the Helm Chart with all released Airflow 2 versions, but some new features might only work starting from specific Airflow releases. We might however limit the Helm Chart to depend on minimal Airflow version. -* **Airflow API clients**: SemVer MAJOR and MINOR versions follow MAJOR and MINOR versions of Airflow. - The first MAJOR or MINOR X.Y.0 release of Airflow should always be followed by X.Y.0 release of - all clients. An airflow PATCH X.Y.Z release can be followed by a PATCH release of API clients, only - if this PATCH is relevant to the clients. - The clients then can release their own PATCH releases with bugfixes, independently of Airflow PATCH releases. - As a consequence, each API client will have its own PATCH version that may or may not be in sync with the Airflow - PATCH version. For a specific MAJOR/MINOR Airflow version, users should favor the latest PATCH version of clients - independently of their Airflow PATCH version. +* **Airflow API clients**: Their versioning is independent from Airflow versions. They follow their own + SemVer rules for breaking changes and new features - which for example allows to change the way we generate + the clients. ## Version Life Cycle