From that, does that mean we would be producing one "major" release a
year, and it will be the first release of the year?
Kind regards
Paul Angus
________________________________
From: Wido den Hollander <[email protected]>
Sent: 04 August 2026 3:02 PM
To: Harikrishna Patnala <[email protected]>;
[email protected] <[email protected]>
Cc: Paul Angus <[email protected]>
Subject: Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Op 04-08-2026 om 14:02 schreef Harikrishna Patnala:
Hi Wido,
In general, I like the idea too.
What is the plan for the regular release numbering ? As per our current
plan we are doing two release per year, one Regular and one LTS.
This will not change
- 4.25.0 > 25.0
- 4.25.0.1 > 25.0.1
- 4.25.1 > 25.1
The way we release stays the same, we are merely dropping the 4 as a
major. The next major release will then be 26, then 27, etc.
Wido
Regards,
Harikrishna
<https://www.cloudstackcollab.org>
*From: *Wido den Hollander via dev <[email protected]>
*Date: *Tuesday, 4 August 2026 at 4:44 PM
*To: *[email protected] <[email protected]>
*Cc: *Paul Angus <[email protected]>; Wido den Hollander <[email protected]
*Subject: *Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Op 03-08-2026 om 12:11 schreef Paul Angus via dev:
> I'd suggest that we don't need a vote for starting a discussion.
>
> My objection has always been people thinking that we can make jumps
in number while at the same time saying that we are using semantic
versioning. And that there has never been an actual plan as to what
would come after the first jump. At the time, next would have been 5.0)
- but after that was it going to be 6.0, or 5.1, and what are we saying
a major or minor number means. Also, would we be supporting an Ubuntu
style LTS 26.04 (or whatever minor release number)
>
> I couldn't vote for "yes, change it", without
>
> 1.
> people understanding that we're dropping semver (dropping semver
wasn't the problem, it was the principle of people not understanding
what they were voting for and what it meant).
> 2.
> Some semblances of a broad plan regarding numbering and their meaning
going forward. For instance - Are we maintaining Ubuntu style LTS is a
material decision
>
> I'm not against changing it per-se. I just want some clarity
all-round.
Thanks for the feedback. The idea: Drop the 4, keep the rest as-is.
Release schedule stays the same and versioning stays the same.
The "4" prefix has no significant meaning anymore. We will just have
releases and our start will be 25 as we are on 24 at the moment.
In my personal humble opinion I don't think the version number matters
that much, but the 4 simply makes no sense.
See Apple who jumped to year number at some point, was easier to
explain. Ubuntu has been doing this for years, but their April and
October release is something we can't guarantee as a project.
Short: Drop the 4 prefix, nothing changes in this version scheme
iteration.
Wido
>
>
> Kind regards
>
>
>
> Paul Angus
>
>
>
> ________________________________
> From: Daan Hoogland <[email protected]>
> Sent: 03 August 2026 10:48 AM
> To: [email protected] <[email protected]>
> Cc: Wido den Hollander <[email protected]>
> Subject: Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
>
> I like ;)
>
> On Mon, Aug 3, 2026 at 11:37 AM Wido den Hollander via dev
> <[email protected]> wrote:
>>
>> Hello,
>>
>> Over the years there have been many proposals regarding the
versioning
>> of CloudStack. The biggest hurdle has been the "4" as a prefix,
which is
>> useless at the moment.
>>
>> I've looked up many of the proposals and discussions (see below), but
>> none of them went anywhere, they silently died. I want this to
change.
>>
>> Ubuntu and Apple us a versioning system where they prefix with the
year,
>> in 2026 this is "26" and next year it will be "27".
>
> I don't think we need to follow years, I would support it, but the
> basic number would be good enough to me
>>
>> Proposal in the past where to drop the "4" and that would be 20 in
the
>> 4.20 era (2024!!) and this would now be "24" as we are approaching
>> version 4.24.
>>
>> I think this would be the easiest change by making our next release
"25"
>> and not 4.25 anymore, with one note: 25 is very close to (20)27 and
it
>> might be better to jump from 25 to 27 as our next release will be in
>> 2027 after we release 4.24.
>
> Here lies my only concern. This will restrict us to at most one major
> per year. I like our custom of late where we have a non-LTS in spring
> and an LTS in autumn (around CCC)
> If we address this . (i.e. allow for experimental features in some way
> that will not harm more conservative users) I am 100% on board.
>
>> We can go over many details, but in general I'd like to get consensus
>> and get things moving on this topic.
>>
>> Any major objections before I start a VOTE? The VOTE would be that
there
>> will be no 4.25 in 2027, but we will have version "27".
>>
>> Thanks,
>>
>> Wido
>>
>>
>>
>> <2024
>> - Jun 2016 - [DISCUSS] 5.0.0 and 6.0.0 (John Burwell): 5.0 for cruft
>> removal/breaking refactors, 6.0 for architectural redesign.
>> https://lists.apache.org/thread/lcmvvyy098oo07rxzf8gzk56oz1lns95
<https://lists.apache.org/thread/lcmvvyy098oo07rxzf8gzk56oz1lns95>
>> - Jan 2019 - Why CloudStack 5 (Ivan Kudryavtsev): no radical change
to
>> justify a "5"; if it is marketing, just drop the leading "4.".
>> https://lists.apache.org/thread/lwlxs8xgz4glocctf7dv89k5nqqsxmlb
<https://lists.apache.org/thread/lwlxs8xgz4glocctf7dv89k5nqqsxmlb>
>>
>> 2024
>> - Jan 2024 - [PROPOSAL] version naming : drop the 4. (Daan): the
second
>> digit is de facto the major. Variants raised: 5.0, 20.0, and
>> Ubuntu-style YYYY.MM.
>> https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
<https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87>
>> - Jan 2024 - [VOTE] drop first version number and continue with
semantic
>> versioning: closed same day, no conclusion, more discussion
requested.
>> https://lists.apache.org/thread/59m575f9vcvl8gdj9c9v5336gmj3v330
<https://lists.apache.org/thread/59m575f9vcvl8gdj9c9v5336gmj3v330>
>> - Feb 2024 - [VOTE] next version 20 instead of 4.20: several +1, but
>> blocked. Paul Angus -1 (vote conflated dropping the 4 with
adopting
>> semver; digit semantics undefined). Guto -1 from the other side
(only
>> worthwhile if it comes with a breaking-change mechanism). No
result.
>> https://lists.apache.org/thread/4zs8d15ghvvwwro46ry5zjf8fn8x0t88
<https://lists.apache.org/thread/4zs8d15ghvvwwro46ry5zjf8fn8x0t88>
>> - Mar 2024 - Joao's alternative: keep X.Y.Z.N with a fixed cadence
>> (major/2y, minor/6m, patch/2-3m, N for security).
>> https://lists.apache.org/thread/o6o9h3qp8gqrpq4v7o81tl6vp51tkjhg
<https://lists.apache.org/thread/o6o9h3qp8gqrpq4v7o81tl6vp51tkjhg>
>> https://github.com/apache/cloudstack/discussions/8970 <https://
github.com/apache/cloudstack/discussions/8970>
>> - Dec 2024 - CloudStack 5? (Rene Moser): reopened the same question.
>> https://lists.apache.org/thread/hnzp6hnsjyj8593cf6tbgryt1s8z5glq
<https://lists.apache.org/thread/hnzp6hnsjyj8593cf6tbgryt1s8z5glq>
>>
>> 2025
>> - Apr 2025 - [Discussion] Versioning (Joao): three rules proposed -
>> API-breaking changes, DB schema changes and feature removal only
in
>> major versions; naming to be voted separately.
>> https://lists.apache.org/thread/4jk31krsjl8cbp5n8wbt7ypwl65g364j
<https://lists.apache.org/thread/4jk31krsjl8cbp5n8wbt7ypwl65g364j>
>> - May 2025 - [VOTE] Versioning process: not carried. Daan -0 pending
>> exceptions (hypervisor support, security releases); Rohit -1
(binding)
>> mainly on restricting DB schema changes to majors, while being
>> supportive of dropping the "4." itself.
>> https://lists.apache.org/thread/wf8910ln7wqn9g535ob0n04docbn2jzd
<https://lists.apache.org/thread/wf8910ln7wqn9g535ob0n04docbn2jzd>
>> - Sep 2025 - [LTS] Extend LTS support to 24 months: adjacent,
explicitly
>> scoped away from the versioning scheme.
>> https://lists.apache.org/thread/fkl74js7vxml9c29jqmhl2ctsxsq868o
<https://lists.apache.org/thread/fkl74js7vxml9c29jqmhl2ctsxsq868o>
>
>
>
> --
> Daan
