Rohit, I don't mind if we have only one supported version for a while. It will mean more focus on that version and the release process. I have a few remarks though, 1. We have a feature release per LTS, so why not just do the feature release in spring and start the maintenance branch in autumn. We can then for .1 be lenient on new features. If we use year numbers as versions there can never be misunderstanding. 2. Does it make sense to have support for Blocker defects on a branch that has been in maintenance for 18 months already?
On Mon, Sep 8, 2025 at 8:06 AM Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > > 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 > > > -- Daan
