> . Thanks Jarek (or rather Claude?) Or rather thanks humans (Rahul and Jarek) who discussed what is the best approach and agreed to it, and Claude turning the loose discussion into a sold documentation (I helped Claude a bit, correcting it a little when it went astray - same with upcoming 2.11 release. There it hallucinated a bit more - clearly because there were some contradicting and outdated docs).
On Mon, Mar 30, 2026 at 11:37 AM Amogh Desai <[email protected]> wrote: > 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. > > > > ---- > > >
