The way things were:
- Day 0: OpenStack release happens.
- Month 18: OpenStack release is no longer maintained, is moved into Extended Maintenance (this historically meant a lower level of support and no releases cut)
- At each individual project's leisure, keeping in mind dependencies, they can retire the EM branch at any moment. Obviously, for projects like nova, keystone, or devstack with large dependency lists, there's a huge amount of community pressure to keep them open as long as possible. (This is why there was controversy when Cinder wanted to close their EM branches; it would potentially force projects depending on it to also close their branches).
The way things are now, since that policy was updated:
(Disclaimer: the policy is written in the https link above; below is my understanding of it, not the policy itself. Please read the policy.)
- Day 0: OpenStack release happens (code lives in stable/YYYY.N)
- Month 18: OpenStack release is no longer maintained. If it is a SLURP release, it is moved to unmaintained/ status automatically. (code is moved to unmaintained/YYYY.N)
- Months 30, 42, ...: Each year thereafter when a new SLURP release is cut, a project must evaluate if they wish to continue keeping this older unmaintained branch open. This is explicitly opt-in and requires that branch/project combo have passing CI.
One key problem with the old way: because branches were opened automatically, even projects that didn't have maintainers or users for an old stable branch would have them. That leads to cases like the zuul-config-errors, where CI for a branch is so neglected that it's causing higher level failures that are seen by OpenDev sysadmins.
So with these Ironic changes; IMO you should take them as the Ironic team being honest and open about what branches we're actually maintaining -- when I take the proposed action we won't be dropping support for anything so much as admitting we haven't supported them for months already. Hopefully the recently-landed items to both change the name to "unmaintained" to reflect it's actual status as an old release with minimal maintenance and the opt-in barrier to reduce the incidences of branches dying a slow death without users knowing they are no longer in development.