All, The guidelines on regular & LTS releases [1] defined support timelines for doing maintenance and security releases. Historically we had both regular and LTS releases, however, over time, all releases effectively became LTS releases and made maintenance and release efforts unsustainable. The recent re-introduction of regular releases (starting with v4.21), will allow annual LTS release efforts to be more sustainable moving forward (the next LTS v4.22 is already in the works).
Adopting a cadence of one regular release and one LTS release annually will improve sustainability. This (old) model will enable us to deliver feature-rich regular releases (typically supported until the next release or up to six months, whichever comes first), while allowing us to focus more thoroughly on LTS releases. As a result, we can potentially extend LTS support timeline from 18 to 24 months. That said, this transition presents a short-term challenge -- once v4.20 reaches EOL in July 2026, only one actively supported LTS release (v4.22) will remain, creating a temporary gap in overlapping LTS support. Considering this, the following two changes are proposed in the LTS guidelines [1]: 1. Extend the LTS support cycle [1], from 18 to 24 months as follows: LTS branches are supported for a total of 24 months in the following manner: * 1-18 months: All defect fixes, improvements, as well as Blocker, Critical, CVEs fixes identified in the LTS branch will be merged and shipped as part of proactive maintenance releases. * 18-24 months: All Blocker defects and CVEs that impact the LTS branch will be merged and shipped as part of security/maintenance releases as needed. 2. Extend the EOL date for 4.20 from 1st July 2026 to 1st Jan 2027, i.e. by 6-months. Please review and share your thoughts and comments. A formal vote may not be necessary if there are no objections. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS Thanks and Regards, Rohit Yadav
