**otherwise I think it may not be always possible to enforce ... Regards.
________________________________ From: Rohit Yadav <[email protected]> Sent: Friday, September 19, 2025 14:33 To: [email protected] <[email protected]> Cc: users <[email protected]> Subject: Re: [LTS] Extend LTS support to 24 months Thanks all for chiming in -- glad to see there's no objection to the proposed benefit for our user community. In the last few rounds we've been slowed by tremendous maintenance and security work because of which releases were in some cases pushed more than 6-months apart. Hopefully if we have 4.22 before end of the year then maybe starting next year, we can aim for a regular release in the first half of the year followed by a LTS release in the second half. And again, that shouldn't stop anybody to do more feature/regular releases if that want. As a community of volunteers, we can only agree on some release schedule guidelines and timelines, otherwise I think it may be always possible to enforce it. That said, my (employee-owned) employer has been supporting and sponsoring some of my and colleagues' time and resources towards release efforts and hope we'll continue to make progress on best-case basis. Regards. ________________________________ From: Daan <[email protected]> Sent: Tuesday, September 16, 2025 13:51 To: [email protected] <[email protected]> Subject: Re: [LTS] Extend LTS support to 24 months João et al, How I read Rohit's proposal, and what I agree to, is that we do not set a feature release schedule yet, but only focus and commit to setting an LTS release schedule of once a year. Those releases would than be maintained for two years. It will than be easier to refuse features for those and only accept features that are already in. I am myself only involved in the functional definition of features and as developer only involved in bug fixing and think this will make life easier for me, both as maintainer and as operator. We are than free to make feature releases whenever someone feels like it and volunteers. also Tata and David and all other users, you are welcome and encouraged to share your opinions. Your opinion is what matters to all of us the most. On 2025/09/09 19:30:43 João Jandre wrote: > Hi, people > > Tata (and all users) please do not be afraid to voice your opinions in > the mailing lists. This is an Apache project and users are as much part > of the community as the devs; please feel free to provide your positive > and negative feedback on the issues discussed on the mailing lists. > > Regarding the topic of this thread, I'm supportive of having both LTS > and non-LTS releases. But I don't see why having both implies that we > must have a bigger LTS window. > > Historically, our "major" releases have had an average of 9 months in > between them. So if we decide that each even release is LTS and each odd > release is non-LTS, we would always have 1 LTS release on average in the > 18 months of support. > > Changing the 18 months to 24 months will not fix this. > > We would only be able to maintain two LTS releases at the same time if > each release was 6 months apart; in a 24 months period we would have 2 > LTS and 2 non-LTS releases. > > Now the problem is: we do not have a release schedule set; the PMC can't > (shouldn't) enforce this without a discussed and approved process for > releases. > > I don't think this discussion makes sense in a vacuum, it must include > the release process discussion. > > Best regards, > > João Jandre > > On 9/8/25 10:56, Rohit Yadav wrote: > > All - this thread is NOT about versioning scheme or releases process. > > > > For those who want tl;dr - this thread is only about LTS release support > > timeline, extending the support from 18 to 24 months. > > > > > > Regards. > > > > > > > > > > ________________________________ > > From: Chi vediamo <[email protected]> > > Sent: Monday, September 8, 2025 17:36 > > To: [email protected] <[email protected]> > > Cc: [email protected] <[email protected]> > > Subject: Re: [LTS] Extend LTS support to 24 months > > > > I am with you Daan, > > > > Apologies. Not sure If I Should have a voice here - as you are both and > > @wei are masters of this platform - > > I am with you both on this idea. > > > > There has to be a froze date established for new features. While something > > defined as Feature Improvement will have to wait until Next minor release - > > even For existing features - If it's following the semantic versioning > > MajorYear.Minor.patch > > If the Major will Keep as 4. the minor release can have 3 digits QYY first > > digit the Quarter and 2 digits for the year Major,QYY,patch > > > > > > Tata Y. > > > > > > > >> On Sep 8, 2025, at 3:43 AM, Daan Hoogland <[email protected]> wrote: > >> > >> 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 <[email protected]> > >> 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 >
