How Angular Chooses and Ships New Features
summary
Angular ships major releases every six months (typically May and November) and treats releases as time-based releases, not feature guarantees; features land only when ready. Prioritization uses GitHub data, yearly surveys, RFCs and user studies, with work queued into a top 20 / next 50 / 500 bucket system. Maintenance (triage, reviews, weekly releases, dependency updates) consumes about 40% of team capacity. Breaking changes land only in a ~10-week major-window and are tested against a monorepo of 4,000+ apps with migrations provided when feasible.
AI-written summary · about
chapters (21)
- 0:00Angular feature planning
- 1:03Angular release timing
- 2:49Time-based releases
- 3:30Brainstorming and prioritization
- 4:56Gathering feature ideas
- 7:05Continuous planning
- 8:49Team capacity vs projects
- 10:12Strategic roadmapping
- 10:56Angular maintenance work
- 11:59GitHub issues and PRs
- 13:03Open-source maintenance scale
- 14:26Why issues stay open
- 16:12Factors in issue handling
- 17:16Issue commonality effects
- 18:43Breaking changes challenges
- 20:29Migrations and breaking changes
- 21:55Why Angular says no
- 22:37Google-scale Angular
- 24:02New features vs tech debt
- 24:46Engaging with Angular team
- 26:56Closing remarks and Q&A
