[airflow] branch main updated: Add rules describing SemVer approach for various Airflow packages. (#16422)

[po...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git


The following commit(s) were added to refs/heads/main by this push:
     new d2448a6  Add rules describing SemVer approach for various Airflow packages. (#16422)
d2448a6 is described below

commit d2448a6b72db1698da786826c6ebb3e36628d658
Author: Jarek Potiuk <ja...@potiuk.com>
AuthorDate: Mon Jun 14 09:49:39 2021 +0200

    Add rules describing SemVer approach for various Airflow packages. (#16422)
---
 README.md | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/README.md b/README.md
index 1b1bdbb..d1549d5 100644
--- a/README.md
+++ b/README.md
@@ -44,6 +44,7 @@ Use Airflow to author workflows as directed acyclic graphs (DAGs) of tasks. The
 
 - [Project Focus](#project-focus)
 - [Principles](#principles)
+- [Semantic versioning](#semantic-versioning)
 - [Version Life Cycle](#version-life-cycle)
 - [Requirements](#requirements)
 - [Support for Python and Kubernetes versions](#support-for-python-and-kubernetes-versions)
@@ -76,6 +77,35 @@ Airflow is not a streaming solution, but it is often used to process real-time d
 - **Elegant**:  Airflow pipelines are lean and explicit. Parameterizing your scripts is built into the core of Airflow using the powerful **Jinja** templating engine.
 - **Scalable**:  Airflow has a modular architecture and uses a message queue to orchestrate an arbitrary number of workers.
 
+## Semantic versioning
+
+As of Airflow 2.0.0, we support strict [SemVer](https://semver.org/) approach for all packages released.
+
+There are few specific rules that we agreed to, that define details of versioning of the different
+packages:
+
+* **Airflow**: SemVer rules apply to core airflow only (excludes any changes to providers).
+  Changing limits for versions of Airflow dependencies is not a breaking change on its own.
+* **Airflow Providers**: SemVer rules apply to changes in the particular provider's code only.
+  SemVer MAJOR and MINOR versions for the packages are independent from Airflow version.
+  For example `google 4.1.0` and `amazon 3.0.3` providers can happily be installed
+  with `Airflow 2.1.1`. If there are limits of cross-dependencies between providers and Airflow 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 be sometimes breaking changes that might make some, or all
+  providers, to 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 undesired side effect of upgrading provider).
+* **Airflow Helm Chart**: SemVer rules apply to changes in the chart only. SemVer MAJOR and MINOR
+  versions for the chart are independent from 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 Airlfow 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 version 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. The clients then can release their own PATCH releases with bugfixes,
+  independently of Airflow PATCH releases.
+
 ## Version Life Cycle
 
 Apache Airflow version life cycle: