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
