Update README_AIRFLOW3_DEV.md (#50444)

Author: shahar1

dev/README_AIRFLOW3_DEV.md

@@ -45,66 +45,61 @@
 
 # Main branch is Airflow 3
 
-The `main` branch is for development of Airflow 3.
-Airflow 2.10.x releases will be cut from `v2-10-stable` branch.
+The `main` branch is for development of Airflow 3.x.
+Airflow 3.0.x releases will be cut from `v3-10-stable` branch.
 Airflow 2.11.x releases will be cut from `v2-11-stable` branch.
 
 # Contributors
 
-The following section explains to which branches you should target your PR.
+The following section explains which branches you should target with your PR.
 
-## Developing for providers and Helm chart
+## Developing for Providers and the Helm Chart
 
-PRs should target `main` branch.
-Make sure your code is only about Providers or Helm chart.
-Avoid mixing core changes into the same PR
+PRs should target the `main` branch.  
+Make sure your changes are only related to Providers or the Helm chart.  
+Avoid mixing core changes into the same PR.
 
 > [!NOTE]
 > Please note that providers have been relocated from `airflow/providers` to `providers/<provider_id>/src/airflow/providers`.
 
-## Developing for Airflow 3 and 2.10.x / 2.11.x
+## Developing for Airflow 3 and 2.11.x
 
-If the PR is relevant for both Airflow 3 and 2, it should target `main` branch.
+If the PR is relevant to both Airflow 3 and 2.11.x, it should target the `main` branch.
 
 > [!IMPORTANT]
-> The mental model of Airflow 2.11 is a bridge release for Airflow 3.
-> As a result, Airflow 2.11 is not planned to introduce new features other than ones relevant to the bridge release for Airflow 3.
-> That said, we recognize that there may be exceptions.
-> If you believe a specific feature is a must-have for Airflow 2.11, you will need to raise this as a discussion thread on the mailing list.
+> Airflow 2.11 is intended as a bridge release for Airflow 3.
+> As such, it is not expected to introduce new features beyond those relevant to the transition to Airflow 3.
+> That said, we recognize there may be exceptions.
+> If you believe a specific feature is essential for Airflow 2.11, please start a discussion thread on the mailing list.
 > Points to address to make your case:
 >
 > 1. You must clarify the urgency, specifically why it can't wait for Airflow 3.
-> 2. You need to be willing to deliver the feature for both the `main` branch and the Airflow 2.11 branch.
+> 2. You need to be willing to deliver the feature for both the `main` branch and the `v2-11-test` branch (either by automatic or manual backporting).
 > 3. You must be willing to provide support for future bug fixes as needed.
 >
-> Points to consider on how PMC members evaluate the request for exception:
+> Points PMC members consider when evaluating exception requests:
 >
-> 1. Feature impact - Is it really urgent? How many are affected?
-> 2. Workarounds - Are there any?
-> 3. Scope of change - Both in code lines / number of files and components changed.
-> 4. Centrality - Is the feature at the heart of Airflow (scheduler, dag parser) or peripheral.
-> 5. Identity of the requester - Is the request from/supported by a member of the community?
-> 6. Approved cases with similar details in the past.
-> 7. Other considerations that may be raised by PMC members depending on the case.
+> 1. **Feature impact** – Is it truly urgent? How many users are affected?
+> 2. **Workarounds** – Are viable alternatives available?
+> 3. **Scope of change** – How extensive is the change (e.g., number of lines, files, or components affected)?
+> 4. **Centrality** – Does the feature affect core parts of Airflow (e.g., scheduler, DAG parser) or more peripheral areas?
+> 5. **Community support** – Is the request made or endorsed by an active community member?
+> 6. **Precedents** – Have similar cases been approved in the past?
+> 7. **Other considerations** – Any additional factors PMC members may raise based on the specific context.
 
 ## Developing for Airflow 3
 
 PRs should target `main` branch.
 
-## Developing for Airflow 2.10.x
-
-PR should target `v2-10-test` branch. When cutting a new release for 2.10 release manager
-will sync `v2-10-test`  branch to `v2-10-stable` and cut the release from the stable branch.
-PR should never target `v2-10-stable` unless specifically instructed by release manager.
+## Developing for Airflow 2.11.x
 
-## Developing for Airflow 2.11
+If a PR can be cleanly cherry-picked from `main` to `v2-11-test`, it should target the `main` branch and include the `backport-to-v2-11-test` label to automate the backport.  
+If the PR cannot be cherry-picked without conflicts, you must manually create a PR targeting the `v2-11-test` branch.
 
-Version 2.11 is planned to be cut from `v2-10-stable` branch.
-The version will contain features relevant as bridge release for Airflow 3.
-We will not backport other features from `main` branch to 2.11.
+When preparing a new 2.11.x release, the release manager will sync the `v2-11-test` branch to `v2-11-stable` and cut the release from the stable branch.  
+PRs should **never** target `v2-11-stable` directly unless explicitly instructed by the release manager.
 
-> [!WARNING]
-> Airflow 2.11 policy may change as its release becomes closer.
+Only features relevant to the Airflow 3 bridge should be backported to 2.11. Other features from the `main` branch will not be backported.
 
 # Committers / PMCs
 
@@ -139,16 +134,16 @@ Python developers. It allows to easily cherry-pick PRs from one branch to anothe
 command line and via GitHub Actions interface.
 
 
-## Merging PR for Airflow 3 and 2.10.x / 2.11.x
+## Merging PR for Airflow 3 and 2.11.x
 
-The committer who merges the PR is responsible for backporting the PR to `v2-10-test`.
+The committer who merges the PR is responsible for backporting the PR to `v2-11-test`, when it's possible and desirable to do so.
 It means that they should create a new PR where the original commit from main is cherry-picked and take care for resolving conflicts.
-If the cherry-pick is too complex, then ask the PR author / start your own PR against `v2-10-test` directly with the change.
+If the cherry-pick is too complex, then ask the PR author / start your own PR against `v2-11-test` directly with the change.
 Note: tracking that the PRs merged as expected is the responsibility of committer who merged the PR.
 
-Committer may also request from PR author to raise 2 PRs one against `main` branch and one against `v2-10-test` prior to accepting the code change.
+Committer may also request from PR author to raise 2 PRs one against `main` branch and one against `v2-11-test` prior to accepting the code change.
 
-Mistakes happen, and such backport PR work might fall through cracks. Therefore, if the committer thinks that certain PRs should be backported, they should set 2.10.x milestone for them.
+Mistakes happen, and such backport PR work might fall through cracks. Therefore, if the committer thinks that certain PRs should be backported, they should set 2.11.x milestone for them.
 
 This way release manager can verify (as usual) if all the "expected" PRs have been backported and cherry-pick remaining PRS.
 
@@ -166,7 +161,7 @@ You can pin the workflow from the list of workflows for easy access to it.
 ![Backport commit](images/backport_commit_action.png)
 
 Use `main` as source of the workflow and copy the commit hash and enter the target branch name
-(e.g. `v2-10-test`, `v3-0-test`).
+(e.g. `v2-11-test`, `v3-0-test`).
 
 The action should create a new PR with the cherry-picked commit and add a comment in the PR when it is
 successful (or when it fails). If automatic backporting fails because of conflicts, you have to revert to
@@ -177,7 +172,7 @@ manual backporting using `cherry-picker` CLI.
 Backporting via CLI might be more convenient for some users. Also it is necessary if you want to backport
 PR that has conflicts. It also allows to backport commit to multiple branches in the same command.
 
-To backport PRs to any branch (for example v2-10-test), you can use the following command:
+To backport PRs to any branch (for example: v2-11-test), you can use the following command:
 
 It's easiest to install it (and keep cherry-picker up-to-date) using `uv tool`:
 
@@ -231,10 +226,9 @@ cherry_picker --continue  # Should continue cherry-picking process
 > you might need to run `git config --local --remove-section cherry-picker` to clean up the configuration
 > stored in `.git/config`.
 
-## Merging PRs 2.10.x
+## Merging PRs for Airflow 2
 
-Make sure PR targets `v2-10-test` branch and merge it when ready.
-Make sure your PRs target the `v2-10-test` branch, and it can be merged when ready.
+Make sure PR targets `v2-11-test` branch and merge it when ready.
 All regular protocols of merging considerations are applied.
 
 ## Merging PRs for Airflow 3