shubham22 commented on code in PR #24680: URL: https://github.com/apache/airflow/pull/24680#discussion_r910483211
########## README.md: ########## @@ -410,6 +410,47 @@ For example this means that by default we upgrade the minimum version of Airflow to 2.3.0 in the first Provider's release after 11th of October 2022 (11th of October 2021 is the date when the first `PATCHLEVEL` of 2.2 (2.2.0) has been released. +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) +which describes who releases, and how to release the ASF software. The provider's governance model is something we name +"mixed governance" - where we follow the release policies, while the burden of maintaining and testing +the cherry-picked versions is on those who commit to perform the cherry-picks and make PRs to older +branches. + +The "mixed governance" means that: + +* The Airflow Community and release manager decide when to release those providers. + This is fully managed by the community and the usual release-management process following the + [Apache Software Foundation release policy](https://www.apache.org/legal/release-policy.html) +* The contributors (who might or might not be direct stakeholders in the provider) will carry the burden + of cherry-picking and testing the older versions of providers. Review Comment: Thanks for clarifying. 1. Aligning this with the current PR process makes complete sense. Can't wait to see this process playing out. 2. The answer to the 1st question that the cherry-picking will go hand in hand with the PR process makes it very clear. You're right, we can resolve the conflicts as they arise, instead of documenting solution path for every scenario. > there will be a lot of people who would "want" this to happen, there will be very few who will "make it happen" I very much concur on this. ########## README.md: ########## @@ -410,6 +410,47 @@ For example this means that by default we upgrade the minimum version of Airflow to 2.3.0 in the first Provider's release after 11th of October 2022 (11th of October 2021 is the date when the first `PATCHLEVEL` of 2.2 (2.2.0) has been released. +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) +which describes who releases, and how to release the ASF software. The provider's governance model is something we name +"mixed governance" - where we follow the release policies, while the burden of maintaining and testing +the cherry-picked versions is on those who commit to perform the cherry-picks and make PRs to older Review Comment: > This is mostly dirty, boring and ground work to be done, nothing really "cool". I've been doing it for years, so I know what I am talking about :) Fair enough :) Agree with your current language given the context you shared. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
