Hey, This is actually not an uncommon misconception. The TC just passed new policy ( https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branch... ) to try and clarify it. 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. Hope this helps, Jay Faulkner Ironic PTL TC Vice-Chair On Thu, Aug 24, 2023 at 7:27 AM Thomas Goirand <thomas@goirand.fr> wrote:

On 8/23/23 22:21, Jay Faulkner wrote:

...

Hi all,

Ironic is one of the major offenders remaining in the work to cleanup Zuul config errors. To resolve these issues, it's my plan to retire any impacted branches unless a contributor volunteers to clean them up. I will give folks until at least September 1, 2023, to object before I begin to take action.

In fact, this makes me question how it works in OpenStack in general. It feels like many projects are doing their ways, and deprecating old branches in different ways. Sometimes, this happens when a CVE can't be addressed in a proper way.

So I wonder: what's the promised lifecycle of a release, and why this is different depending on the project? Aren't we committed to maintain at last the latest 3 releases? If so, then deprecating any branch before Yoga is currently fine, no? If so, why are projects keeping stable branches opened for longer?

Cheers,

Thomas Goirand (zigo)