Another thing that is not clear to me is who defines that transition between general stable branch state into 'Security-supported' one. Are there any written rules for that, like binding such transition to trunk milestones?
What is community supported is a function of resources available and historical experience with bitrot in N-1 branches, expanding the support scope for N-1 stable branch is fine if we can deliver it. We didn't have that written down, but traditionally when N is released it becomes "Current stable release, security-supported" and N-1 "downgraded" to "Security-supported" only. N-1 was going EOL around N+1 milestone3 but we have extended that to 15 months at last design summit. IIRC "current stable release" was originally defined by markmc as the branch where stable-maint team proactively proposes backports by monitoring the trunk, but we have lost that mode long ago, backports are now done retroactively after bugs are reported. To clarify, I propose following wording to be added to https://wiki.openstack.org/wiki/StableBranch#Releases When new OpenStack version is released it becomes "Current stable release, security-supported"" and previous version "Security-supported". "Current stable release" is the primary target for backports of bugfixes by the stable-maint team, other active branches may receive bugfix backports. "Security-supported" releases are target for the security fixes by the [[Vulnerability_Management#Supported_versions|VMT]] OpenStack Havana stable release will reach EOL at Juno (N+2) milestone-3 and stable releases starting from Icehouse will reach EOL 15 months after their release (approximately N+3 milestone-2). Cheers, Alan