potiuk commented on code in PR #24680:
URL: https://github.com/apache/airflow/pull/24680#discussion_r907964660


##########
README.md:
##########
@@ -410,6 +410,27 @@ 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.
 
+Since providers are often connected with some stakeholders that are vitally 
interested in maintaining
+their integrations (for example cloud providers, ore specific service 
providers), and we are also bound with
+the Apache Software Foundation release policies. The provider's governance 
model is something we name
+"mixed governance".
+
+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.
+
+Usually, we release only the most recent version of the provider and rather 
aggressively
+remove deprecations in "major" versions of the providers, however the 
stakeholder in a given provider might
+agree and make their effort on cherry-picking the non-breaking changes to a 
selected previous major branch
+of the provider which results in releasing more (usually two) versions of such 
provider when we release it:
+potentially breaking "latest" major version, and selected past major version 
with non-breaking changes
+applied by the stakeholder (cherry-picked changes have to be merged by the 
committer following the usual
+rules of the community).
+
+The community continues to release such older versions of the providers for as 
long as there is an effort
+of the stakeholder to maintain the cherry-picked changes. The availability of 
the 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.

Review Comment:
   > Not sure what message you want to convey here. Is this paragraph necessary?
   
   This is all about managing the expectations of the users. What we are 
writing here as a policy is a policy that our users will be able (and they will 
do it) to call us upon. This happened multiple times ("but you wrote here that 
you are doing it"). The message was that the users should not *expect* older 
versions to be released - if there is no-one to cherry-pick them we (as 
maintainers) will not be expected to release the older versions. I updated it 
slighttly
   
   > I think this is a very important paragraph, and if anything, should be 
expanded! And also made more concrete.
   
   I did.
   
   > This leaves the door open to having some very old actrive branches grin
   
   True. But I added "to perform the cherry-picks and carry-on testing of the 
older provider version." - the testing part will limit it significantly. I also 
changed in the previous paragrapsh "usually two version" to "maximum two 
versions". That should help.
   
   > We should formalize what level of availability is required and make it 
concrete what such an agreement looks like. Is that a PR to a piece of 
code/documentation? A chain on the dev list? Something else entirely?
   
   I think there wil never be formal agreement - this will always be slightly 
"vague" statement. Driving willingess is gooo enough IMHO as an indication that 
there is a relation between the availabilihty and likelihood of being accepted. 
From the community side - everything in the ASF and "Apache Way" it's all 
driven by consensus - if we cannot achieve, we vote. From the "stakeholder" 
point of view - this is "well, when I contribute and want to release older 
versions, I or others will have to commit to cherry-pick to and test the older 
versions. This is the "responsibility" I am committing to.
   



-- 
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: commits-unsubscr...@airflow.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to