BasPH commented on code in PR #24680: URL: https://github.com/apache/airflow/pull/24680#discussion_r909922469
########## README.md: ########## @@ -410,6 +410,44 @@ 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 and how releases 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 still decides when to release those providers. Review Comment: ```suggestion * The Airflow Community and release manager decide when to release those providers. ``` ########## README.md: ########## @@ -410,6 +410,44 @@ 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 and how releases the ASF software. The provider's governance model is something we name Review Comment: ```suggestion which describes who releases, and how to release the ASF software. The provider's governance model is something we name ``` ########## README.md: ########## @@ -410,6 +410,44 @@ 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 and how releases 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 still decides 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. + +Usually, we release only the most recent version of the provider and rather aggressively +remove deprecations in "major" versions of the providers, however if there is a contributor willing to +make their effort on cherry-picking and testing the non-breaking changes to a selected previous major branch +of the provider which results in releasing maximum two versions of such provider when we release it: + +* potentially breaking "latest" major version +* selected past major version with non-breaking changes applied by the contributor + +Cherry-picking such changes follows the process that we already follow for releasing Airflow +patch-level releases for previous minor Airflow version. Usually such cherry-picking is done when +there is an important bugfix but the latest version contains breaking changes which are not +coupled with the bugfix (but releasing them together in the latest version of provider effectively couples +them). The cherry-picked changes have to be merged by the committer following the usual rules of the Review Comment: ```suggestion patch-level releases for a previous minor Airflow version. Usually such cherry-picking is done when there is an important bugfix and the latest version contains breaking changes that are not coupled with the bugfix. Releasing them together in the latest version of the provider effectively couples them, and therefore they're released separately. The cherry-picked changes have to be merged by the committer following the usual rules of the ``` ########## README.md: ########## @@ -410,6 +410,44 @@ 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 and how releases 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 still decides 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. + +Usually, we release only the most recent version of the provider and rather aggressively +remove deprecations in "major" versions of the providers, however if there is a contributor willing to +make their effort on cherry-picking and testing the non-breaking changes to a selected previous major branch +of the provider which results in releasing maximum two versions of such provider when we release it: Review Comment: This whole paragraph is a single sentence and I don't understand it. Could you split into into multiple sentences for readability? For example: > Usually, we release only the most recent version of the provider and rather aggressively remove deprecations in "major" versions of the providers. However, .... ########## README.md: ########## @@ -410,6 +410,44 @@ 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 and how releases 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 still decides 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. + +Usually, we release only the most recent version of the provider and rather aggressively +remove deprecations in "major" versions of the providers, however if there is a contributor willing to +make their effort on cherry-picking and testing the non-breaking changes to a selected previous major branch +of the provider which results in releasing maximum two versions of such provider when we release it: + +* potentially breaking "latest" major version +* selected past major version with non-breaking changes applied by the contributor + +Cherry-picking such changes follows the process that we already follow for releasing Airflow Review Comment: ```suggestion Cherry-picking such changes follows the same process for releasing Airflow ``` -- 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]
