Public release windows: when your Flutter PR ships to stable
Open-source planning used to be fuzzy. Flutter now publishes release windows — branch cutoff dates that guarantee inclusion in the next stable.
2026 stable train (as announced with 3.41)
| Release | Target | Branch cutoff |
|---|---|---|
| 3.41 | February | 06 January |
| 3.44 | May | 07 April |
| 3.47 | August | 07 July |
| 3.50 | November | 06 October |
Merge before cutoff → ships in that stable. Merge after → next train.
How teams should use this
- Plugin authors: align breaking changes with cutoffs, not with your sprint end.
- App teams: schedule upgrades after each stable + a bake week.
- Contributors: say the target release in the PR description.
Pitfalls
- Cutoff is not “code freeze forever” — cherry-picks still exist, but do not plan on them.
- Beta/main features can slip; read the release notes each time.