potiuk commented on PR #24680: URL: https://github.com/apache/airflow/pull/24680#issuecomment-1168112687
> 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 3. when this cherry-picking stops maintainers have no obligationas to release those older versions of providers 4. 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). 5. users can expect that in some cases (when somoene steps up) there might be older backwards-compatible versions of the providers 6. 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. 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. -- 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]
