Update release process for Providers

[potiuk]

This release process updates Provider's release approach and
"mixed-governance" model after the discussion and proposal

https://lists.apache.org/thread/6ngq79df7op541gfwntspdtsvzlv1cr6

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragement file, named {pr_number}.significant.rst, in newsfragments.

[BasPH]

I find it hard to wrap my head around what I'm reading. What is the message you want to convey here?

I'd explain the branching model as discussed in https://lists.apache.org/thread/6ngq79df7op541gfwntspdtsvzlv1cr6, perhaps with a picture. And are there resources/channels for the reading of this document to read/ask? E.g. say I'd have a question about the release of a PR in the Google provider, what would I do?

[o-nikolas]

Thanks so much for this Jarek!

[potiuk]

I find it hard to wrap my head around what I'm reading. What is the message you want to convey here?

Ok. Cool. I am happy to iterate on it to make it better :).

This is indeed not easy task, but the mssage I want to convey is:

1. In some cases we want to release past providers (when there is someone to drive the cherry-picking and those who drive cherry-picking are not maintainers
2. when this cherry-picking stops, maintainers have no obligationas to release those older versions of providers
3. this is a process that will likely apply to those providers that have strong stakeholders behind (but maybe I was not clear this is not a prerequisite) - anyone can step-up and - and commit to maintaining older version of provider and cherry-pick changes (via PR).
4. users can expect that in some cases (when somoene steps up) there might be older backwards-compatible versions of the providers
5. those stakeholders who want to contribute new community airfflow providers have to think twice knowing that we have some expectation about future maintenance of those

I'd explain the branching model as discussed in https://lists.apache.org/thread/6ngq79df7op541gfwntspdtsvzlv1cr6, perhaps with a picture. And are there resources/channels for the reading of this document to read/ask? E.g. say I'd have a question about the release of a PR in the Google provider, what would I do?

I wanted to avoid going into too many details, those are mostly technicalities and we are already doing the very same process for v2* branches of airlfow - here just branching point and branch name is different. I might modify it and merge the policy first and then turn it into a "dev recipe" on how to do it (as usual - I have a habit of meticulously detailing the technical processes we follow - but that belongs to "dev" rather than README and I wanted to separate those two - and document the "technical" side of the process after we do it for the first time (because otherwise it will be a little guessing and will have many more mistakes.
But I will just add that we use the same process as when cherry-picking to v2* branches of Airflow

There is no "special" handling or questions about released providers. This does not introduce a new way of answering the questions "what is in provider of version x" comparing to today. Say - you want to get answers about what is in 7.0.0 version of Google Provider - you will find it here: https://airflow.apache.org/docs/apache-airflow-providers-google/7.0.0/index.html#changelog . If we release 7.1.0, it will be https://airflow.apache.org/docs/apache-airflow-providers-google/7.1.0/index.html#changelog (now defunct). The index of those is built automatically. And SemVer answer all the questions about backwards compatibility/features of each of providers, so the user can decide which version to upgrade to (if they upgrade providers separately):

• 7.1.0 - if they care about backwards-compatibility and they need bug-fix released in 7.1.0 (cherry-picked from 8.0.0)
• 8.0.0 - if they care about new features/bugfixes that were not released in 7.1.0

No change in communication there - except that we will be announcing in some cases 2 version of "the same" provider instead of one at the same time. There are no changes at all to Airlfow's approach - we always use the "latest released" providers when releasing new version of Airlfow.

[potiuk]

I pushed a fixup with all those comments so far addressed (hopefully)

[potiuk]

@BasPH -> is that at least slightly better now ?

[BasPH]

Looks good, much more concrete now! I've added a few smaller comments, but the general message lgtm.

[shubham22]

Thanks for drafting this Jarek! A big step in the right direction.

[potiuk]

OK. If there are no more comments - I 'd love an approval and we can continue with preparing next provider release following it - I will ping the contributors to past versions that I know are interested in following it up.

[potiuk]

Anyone? I'd love to announce merging it and resolving the "lasy consensus" thread :)