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 600cca1978 Add description of the provider suspension process (#30359)
600cca1978 is described below
commit 600cca197881e3c7d394578d504b77ad7a2eebcc
Author: Jarek Potiuk <[email protected]>
AuthorDate: Tue Apr 4 18:05:42 2023 +0200
Add description of the provider suspension process (#30359)
Following discussion at the devlist, we are adding description
of the suspension process for providers that hold us back from
upgrading old dependencies. Discussion here:
https://lists.apache.org/thread/j98bgw9jo7xr4fvjh27d6bfoyxr1omcm
Co-authored-by: Daniel Standish
<[email protected]>
---
README.md | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/README.md b/README.md
index 0852d40416..ceb079fc3f 100644
--- a/README.md
+++ b/README.md
@@ -404,6 +404,8 @@ might decide to add additional limits (and justify them
with comment)
## Release process for Providers
+### Minimum supported version of Airflow
+
Providers released by the community (with roughly monthly cadence) have
limitation of a minimum supported version of Airflow. The minimum version of
Airflow is the `MINOR` version (2.2, 2.3 etc.) indicating that the providers
@@ -424,6 +426,8 @@ will be able to use the new version without breaking their
workflows. When we up
2.2+, our approach was different but as of 2.3+ upgrade (November 2022) we
only bump `MINOR` version of the
provider when we increase minimum Airflow version.
+### Mixed governance model
+
Providers are often connected with some stakeholders that are vitally
interested in maintaining backwards
compatibilities in their integrations (for example cloud providers, or
specific service providers). But,
we are also bound with the [Apache Software Foundation release
policy](https://www.apache.org/legal/release-policy.html)
@@ -473,6 +477,38 @@ of the contributors to perform the cherry-picks and
carry-on testing of the olde
The availability of stakeholder that can manage "service-oriented" maintenance
and agrees to such a
responsibility, will also drive our willingness to accept future, new
providers to become community managed.
+### Suspending releases for providers
+
+In case a provider is found to require old dependencies that are not
compatible with upcoming versions of
+the Apache Airflow or with newer dependencies required by other providers, the
provider's release
+process can be suspended.
+
+This means:
+
+* The provider's status is set to "suspended"
+* No new releases of the provider will be made until the problem with
dependencies is solved
+* Sources of the provider remain in the repository for now (in the future we
might add process to remove them)
+* No new changes will be accepted for the provider (other than the ones that
fix the dependencies)
+* The provider will be removed from the list of Apache Airflow extras in the
next Airflow release
+ (including patch-level release if it is possible/easy to cherry-pick the
suspension change)
+* Tests of the provider will not be run on our CI (in main branch)
+* Dependencies of the provider will not be installed in our main branch CI
image nor included in constraints
+* We can still decide to apply security fixes to released providers - by
adding fixes to the main branch
+ but cherry-picking, testing and releasing them in the patch-level branch of
the provider similar to the
+ mixed governance model described above.
+
+The suspension may be triggered by any committer after the following criteria
are met:
+
+* The maintainers of dependencies of the provider are notified about the issue
and are given a reasonable
+ time to resolve it (at least 1 week)
+* Other options to resolve the issue have been exhausted and there are good
reasons for upgrading
+ the old dependencies in question
+* Explanation why we need to suspend the provider is stated in a public
discussion in the devlist. Followed
+ by LAZY CONSENSUS or VOTE (with the majority of the voters agreeing that we
should suspend the provider)
+
+The suspension will be lifted when the dependencies of the provider are made
compatible with the Apache
+Airflow and with other providers.
+
## Contributing
Want to help build Apache Airflow? Check out our [contributing
documentation](https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst).
