potiuk commented on code in PR #41457: URL: https://github.com/apache/airflow/pull/41457#discussion_r1716519036
########## dev/README_AIRFLOW3_DEV.md: ########## @@ -0,0 +1,76 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--> +<!-- START doctoc generated TOC please keep comment here to allow auto update --> +<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> +**Table of contents** + +- [Main branch is Airflow 3](#main-branch-is-airflow-3) +- [Developing for providers and Helm chart](#developing-for-providers-and-helm-chart) +- [Developing for Airflow 3](#developing-for-airflow-3) +- [Developing for Airflow 2.10.x](#developing-for-airflow-210x) +- [Developing for Airflow 3 and 2.10.x / 2.11.x](#developing-for-airflow-3-and-210x--211x) +- [Merging PRs 2.10.x](#merging-prs-210x) +- [Merging PRs for Airflow 3](#merging-prs-for-airflow-3) + - [PRs that involve breaking changes](#prs-that-involve-breaking-changes) +- [Merging PR for Airflow 3 and 2.10.x / 2.11.x](#merging-pr-for-airflow-3-and-210x--211x) + +<!-- END doctoc generated TOC please keep comment here to allow auto update --> + +# Main branch is Airflow 3 + +The main branch is for development of Airflow 3. +Airflow 2.10.x releases will be cut from `v-2-10-stable` branch. + +# Developing for providers and Helm chart + +PRs should target `main` branch. + +# Developing for Airflow 3 + +PRs should target `main` branch. + +# Developing for Airflow 2.10.x + +PR should target `v-2-10-test` branch. When cutting a new release for 2.10 release manager +will sync `v-2-10-test` branch to `v-2-10-stable` and cut the release from the stable branch. +PR should never target `v-2-10-stable` unless specificly instructed by release manager. + +# Developing for Airflow 3 and 2.10.x / 2.11.x + +If the PR is relevant for both Airflow 3 and 2 it should target `main` branch. + +# Merging PRs 2.10.x + +Make sure PR target `v-2-10-test` branch and merge it when ready. +All regular protocols of merging considerations are applied. + +# Merging PRs for Airflow 3 + +Make sure PR target `main` branch. + +## PRs that involve breaking changes + +Make sure it has newsfragment, please allow time for community members to review. +Our goal is to avoid breaking changes if we can so we should allow time to review, don't rush to merge. + +# Merging PR for Airflow 3 and 2.10.x / 2.11.x + +The committer who merge the PR is responsible for cherry pick the PR to `v-2-10-test` +If cherry pick is too complex then ask the PR author / start your own PR against `v-2-10-test` directly with the change. +Note: tracking that the PRs merged as expected is the responsibility of committer who merged the PR. Review Comment: I did cherry-picking originall following the original description but as explained by @ephraimbuddy in https://apache-airflow.slack.com/archives/C03G9H97MM2/p1723409003786549 - we have "branch-protection" enabled for v2-10-test, so the only way is to make PR against v2-10-test. @ephraimbuddy @utkarsharma2 -> do I understand correctly? Was that the intention here? It is quite a burden on the committer merging change (however it makes release manager's job much easier) - and there are pros and cons. For one they might meke people more hesitant to merge PRs when they **should** be also backported, because rather than clicking a button and setting a label, it requires them to actually backport the change and possibly resolve conflicts (which so far was release manager's job). But also yes, it allows to more easily gate and make sure that what's get "backported" is verified and approved by someone else, it's not an individual decision. I am quite ok with the burden, as long as all committers are aware of that. I thknk if we do not communicate it explicitly and explain that this is "expectation" - we might end up with people having different expectation and not making such PRs - because they will think it will somehow "magically" happen. -- 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]
