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 <[email protected]>
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:
