I might be too quick to respond here, but it totally makes sense and the PR looks good as well. Thanks Jarek (or rather Claude?)
Thanks & Regards, Amogh Desai On Mon, Mar 30, 2026 at 3:03 PM Jarek Potiuk <[email protected]> wrote: > We discussed it with Rahul. Since he is busy managing the release, I > offered to help communicate the way to work between now and the final 3.2.0 > release. > > Based on our Slack conversation I (or rather Claude - I literally pasted > the conversation from Slack to Claude to generate this): > > Here is the PR: https://github.com/apache/airflow/pull/64462/ > > We generally work as usual except for how we cherry-pick changes targetted > for 3.2.1: > > ----- > > ## Backporting during pre-release period (before 3.2.0 GA) > > During the pre-release period (after a beta/RC has been cut but before > 3.2.0 GA is released), we need to > be careful about what gets merged into `v3-2-test` to avoid introducing > risk into the upcoming release. > > The following types of changes **can be merged directly** into `v3-2-test` > during the pre-release period: > > * **dev/CI changes** — keeping CI green and workflows up-to-date > * **Security fixes** — critical security patches > * **Fixes for issues found in the beta/RC** — bugs discovered during > beta/RC testing > > For **bug fixes targeting 3.2.1** (i.e., fixes that are not critical for > the 3.2.0 release): > > 1. Merge the PR to `main` as usual. > 2. Cherry-pick it to `v3-2-test` (either automatically via label or > manually). > 3. Set the **3.2.1 milestone** on the PR. > 4. **Keep the backport PR as a Draft** — do not merge it until 3.2.0 GA is > released. > 5. After 3.2.0 GA is released, go back and merge the draft backport PRs. > > This approach avoids creating additional branches while ensuring that 3.2.0 > is not destabilized by changes that are not strictly necessary for the > initial release. > > ---- >
