You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Wido den Hollander via dev <de...@cloudstack.apache.org> on 2026/08/03 09:37:41 UTC
[DISCUSS] Versioning of CloudStack in 2027 and beyond
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".
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.
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
- 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
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
- 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
- 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
- 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://github.com/apache/cloudstack/discussions/8970
- Dec 2024 - CloudStack 5? (Rene Moser): reopened the same question.
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
- 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
- Sep 2025 - [LTS] Extend LTS support to 24 months: adjacent, explicitly
scoped away from the versioning scheme.
https://lists.apache.org/thread/fkl74js7vxml9c29jqmhl2ctsxsq868o
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Andrija Panic <an...@gmail.com>.
alright - maybe that makes sense, at the end, it's important that things
works, and what version is it.... well, I'm just afraid people will be busy
with internal work to actually care about next polishing steps, but let's
hope for the best.
+1
On Wed, Aug 5, 2026 at 10:14 AM Wido den Hollander via dev <
dev@cloudstack.apache.org> wrote:
>
>
> Op 05-08-2026 om 08:47 schreef Daan Hoogland:
> > Hi all,
> >
> > We can make precise plans or we can take baby steps. Let's just drop
> > the "4." first. We have until the second half of 2028 to go to year
> > versioning if we keep making two major releases per year. We are not
> > strikt enough in our semantic versioning some may argue, but that is
> > notwithstanding we leave the "4." or drop it.
>
> That's my point. Drop the 4 now, do not change anything else. We can
> strive for perfection and do everything top notch when we change this,
> but this has been proposed many times in the last 10 years and it all
> died, nothing happened.
>
> My proposal is simple: Drop the 4 suffix, baby step, see how this works
> in 2027 and take it from there.
>
> Trying to do a major leap at once will probably just die silently, again.
>
> Wido
>
> >
> > On Wed, Aug 5, 2026 at 2:19 AM Andrija Panic <an...@gmail.com>
> wrote:
> >>
> >> Question does stand, indeed (if we want to follow the "year" numbering)
> >> Let's have a clear plan - @Wido den Hollander <wi...@widodh.nl> - why
> don't
> >> we propose details in the same cwiki.confluence/etc - where we keep
> >> current versions, support dates, etc, what do you think?
> >>
> >> #####
> >> Although the below might not be a topic for this thread, perhaps it
> >> actually is very related - we've been deviating from the usual
> practices we
> >> had been practising in past when it comes to major and minor releases
> (let
> >> alone the security releases....)
> >>
> >> - I've seen completely new features being added to minor releases e.g.
> >> 4.22 is a major one, then complete new features land in 4.22.1.0 vs.
> just
> >> fixes and minor changes (driven by whoever decides as such at that
> moment
> >> or is an RM)
> >> - Also, it would be nice to sometimes see other people get involved in
> >> Release Management and not the same people all over again.I'm talking
> only
> >> about getting help, not anything else - because it's mainly my
> >> ex-colleagues who were doing this diligent work - it would be nice for
> more
> >> community members to pick up the RM process, from time to time.
> >>
> >> Happy to see versioning changes anyhow, but with a clear plan.
> >>
> >> Best,
> >> Andrija
> >>
> >> On Tue, Aug 4, 2026 at 10:50 PM Paul Angus via dev <
> >> dev@cloudstack.apache.org> wrote:
> >>
> >>>
> >>> 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 <wi...@widodh.nl>
> >>> Sent: 04 August 2026 3:02 PM
> >>> To: Harikrishna Patnala <Ha...@shapeblue.com>;
> >>> dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> >>> Cc: Paul Angus <pa...@angus.uk.com>
> >>> 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 <de...@cloudstack.apache.org>
> >>>> *Date: *Tuesday, 4 August 2026 at 4:44 PM
> >>>> *To: *dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> >>>> *Cc: *Paul Angus <pa...@angus.uk.com>; Wido den Hollander <
> wido@widodh.nl
> >>>>
> >>>> *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 <da...@gmail.com>
> >>>> > Sent: 03 August 2026 10:48 AM
> >>>> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> >>>> > Cc: Wido den Hollander <wi...@widodh.nl>
> >>>> > 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
> >>>> > <de...@cloudstack.apache.org> 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
> >>>>
> >>>
> >>>
> >>
> >> --
> >>
> >> Andrija Panić
> >
> >
> >
>
>
--
Andrija Panić
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Wido den Hollander via dev <de...@cloudstack.apache.org>.
Op 05-08-2026 om 08:47 schreef Daan Hoogland:
> Hi all,
>
> We can make precise plans or we can take baby steps. Let's just drop
> the "4." first. We have until the second half of 2028 to go to year
> versioning if we keep making two major releases per year. We are not
> strikt enough in our semantic versioning some may argue, but that is
> notwithstanding we leave the "4." or drop it.
That's my point. Drop the 4 now, do not change anything else. We can
strive for perfection and do everything top notch when we change this,
but this has been proposed many times in the last 10 years and it all
died, nothing happened.
My proposal is simple: Drop the 4 suffix, baby step, see how this works
in 2027 and take it from there.
Trying to do a major leap at once will probably just die silently, again.
Wido
>
> On Wed, Aug 5, 2026 at 2:19 AM Andrija Panic <an...@gmail.com> wrote:
>>
>> Question does stand, indeed (if we want to follow the "year" numbering)
>> Let's have a clear plan - @Wido den Hollander <wi...@widodh.nl> - why don't
>> we propose details in the same cwiki.confluence/etc - where we keep
>> current versions, support dates, etc, what do you think?
>>
>> #####
>> Although the below might not be a topic for this thread, perhaps it
>> actually is very related - we've been deviating from the usual practices we
>> had been practising in past when it comes to major and minor releases (let
>> alone the security releases....)
>>
>> - I've seen completely new features being added to minor releases e.g.
>> 4.22 is a major one, then complete new features land in 4.22.1.0 vs. just
>> fixes and minor changes (driven by whoever decides as such at that moment
>> or is an RM)
>> - Also, it would be nice to sometimes see other people get involved in
>> Release Management and not the same people all over again.I'm talking only
>> about getting help, not anything else - because it's mainly my
>> ex-colleagues who were doing this diligent work - it would be nice for more
>> community members to pick up the RM process, from time to time.
>>
>> Happy to see versioning changes anyhow, but with a clear plan.
>>
>> Best,
>> Andrija
>>
>> On Tue, Aug 4, 2026 at 10:50 PM Paul Angus via dev <
>> dev@cloudstack.apache.org> wrote:
>>
>>>
>>> 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 <wi...@widodh.nl>
>>> Sent: 04 August 2026 3:02 PM
>>> To: Harikrishna Patnala <Ha...@shapeblue.com>;
>>> dev@cloudstack.apache.org <de...@cloudstack.apache.org>
>>> Cc: Paul Angus <pa...@angus.uk.com>
>>> 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 <de...@cloudstack.apache.org>
>>>> *Date: *Tuesday, 4 August 2026 at 4:44 PM
>>>> *To: *dev@cloudstack.apache.org <de...@cloudstack.apache.org>
>>>> *Cc: *Paul Angus <pa...@angus.uk.com>; Wido den Hollander <wido@widodh.nl
>>>>
>>>> *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 <da...@gmail.com>
>>>> > Sent: 03 August 2026 10:48 AM
>>>> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
>>>> > Cc: Wido den Hollander <wi...@widodh.nl>
>>>> > 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
>>>> > <de...@cloudstack.apache.org> 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
>>>>
>>>
>>>
>>
>> --
>>
>> Andrija Panić
>
>
>
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Daan Hoogland <da...@gmail.com>.
Hi all,
We can make precise plans or we can take baby steps. Let's just drop
the "4." first. We have until the second half of 2028 to go to year
versioning if we keep making two major releases per year. We are not
strikt enough in our semantic versioning some may argue, but that is
notwithstanding we leave the "4." or drop it.
On Wed, Aug 5, 2026 at 2:19 AM Andrija Panic <an...@gmail.com> wrote:
>
> Question does stand, indeed (if we want to follow the "year" numbering)
> Let's have a clear plan - @Wido den Hollander <wi...@widodh.nl> - why don't
> we propose details in the same cwiki.confluence/etc - where we keep
> current versions, support dates, etc, what do you think?
>
> #####
> Although the below might not be a topic for this thread, perhaps it
> actually is very related - we've been deviating from the usual practices we
> had been practising in past when it comes to major and minor releases (let
> alone the security releases....)
>
> - I've seen completely new features being added to minor releases e.g.
> 4.22 is a major one, then complete new features land in 4.22.1.0 vs. just
> fixes and minor changes (driven by whoever decides as such at that moment
> or is an RM)
> - Also, it would be nice to sometimes see other people get involved in
> Release Management and not the same people all over again.I'm talking only
> about getting help, not anything else - because it's mainly my
> ex-colleagues who were doing this diligent work - it would be nice for more
> community members to pick up the RM process, from time to time.
>
> Happy to see versioning changes anyhow, but with a clear plan.
>
> Best,
> Andrija
>
> On Tue, Aug 4, 2026 at 10:50 PM Paul Angus via dev <
> dev@cloudstack.apache.org> wrote:
>
> >
> > 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 <wi...@widodh.nl>
> > Sent: 04 August 2026 3:02 PM
> > To: Harikrishna Patnala <Ha...@shapeblue.com>;
> > dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Cc: Paul Angus <pa...@angus.uk.com>
> > 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 <de...@cloudstack.apache.org>
> > > *Date: *Tuesday, 4 August 2026 at 4:44 PM
> > > *To: *dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > > *Cc: *Paul Angus <pa...@angus.uk.com>; Wido den Hollander <wido@widodh.nl
> > >
> > > *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 <da...@gmail.com>
> > > > Sent: 03 August 2026 10:48 AM
> > > > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > > > Cc: Wido den Hollander <wi...@widodh.nl>
> > > > 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
> > > > <de...@cloudstack.apache.org> 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
> > >
> >
> >
>
> --
>
> Andrija Panić
--
Daan
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Andrija Panic <an...@gmail.com>.
Question does stand, indeed (if we want to follow the "year" numbering)
Let's have a clear plan - @Wido den Hollander <wi...@widodh.nl> - why don't
we propose details in the same cwiki.confluence/etc - where we keep
current versions, support dates, etc, what do you think?
#####
Although the below might not be a topic for this thread, perhaps it
actually is very related - we've been deviating from the usual practices we
had been practising in past when it comes to major and minor releases (let
alone the security releases....)
- I've seen completely new features being added to minor releases e.g.
4.22 is a major one, then complete new features land in 4.22.1.0 vs. just
fixes and minor changes (driven by whoever decides as such at that moment
or is an RM)
- Also, it would be nice to sometimes see other people get involved in
Release Management and not the same people all over again.I'm talking only
about getting help, not anything else - because it's mainly my
ex-colleagues who were doing this diligent work - it would be nice for more
community members to pick up the RM process, from time to time.
Happy to see versioning changes anyhow, but with a clear plan.
Best,
Andrija
On Tue, Aug 4, 2026 at 10:50 PM Paul Angus via dev <
dev@cloudstack.apache.org> wrote:
>
> 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 <wi...@widodh.nl>
> Sent: 04 August 2026 3:02 PM
> To: Harikrishna Patnala <Ha...@shapeblue.com>;
> dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Cc: Paul Angus <pa...@angus.uk.com>
> 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 <de...@cloudstack.apache.org>
> > *Date: *Tuesday, 4 August 2026 at 4:44 PM
> > *To: *dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > *Cc: *Paul Angus <pa...@angus.uk.com>; Wido den Hollander <wido@widodh.nl
> >
> > *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 <da...@gmail.com>
> > > Sent: 03 August 2026 10:48 AM
> > > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > > Cc: Wido den Hollander <wi...@widodh.nl>
> > > 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
> > > <de...@cloudstack.apache.org> 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
> >
>
>
--
Andrija Panić
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Paul Angus via dev <de...@cloudstack.apache.org>.
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 <wi...@widodh.nl>
Sent: 04 August 2026 3:02 PM
To: Harikrishna Patnala <Ha...@shapeblue.com>; dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Cc: Paul Angus <pa...@angus.uk.com>
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 <de...@cloudstack.apache.org>
> *Date: *Tuesday, 4 August 2026 at 4:44 PM
> *To: *dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> *Cc: *Paul Angus <pa...@angus.uk.com>; Wido den Hollander <wi...@widodh.nl>
> *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 <da...@gmail.com>
> > Sent: 03 August 2026 10:48 AM
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Cc: Wido den Hollander <wi...@widodh.nl>
> > 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
> > <de...@cloudstack.apache.org> 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
>
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Wido den Hollander via dev <de...@cloudstack.apache.org>.
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 <de...@cloudstack.apache.org>
> *Date: *Tuesday, 4 August 2026 at 4:44 PM
> *To: *dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> *Cc: *Paul Angus <pa...@angus.uk.com>; Wido den Hollander <wi...@widodh.nl>
> *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 <da...@gmail.com>
> > Sent: 03 August 2026 10:48 AM
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Cc: Wido den Hollander <wi...@widodh.nl>
> > 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
> > <de...@cloudstack.apache.org> 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
>
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Harikrishna Patnala <Ha...@shapeblue.com>.
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.
Regards,
Harikrishna
From: Wido den Hollander via dev <de...@cloudstack.apache.org>
Date: Tuesday, 4 August 2026 at 4:44 PM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Cc: Paul Angus <pa...@angus.uk.com>; Wido den Hollander <wi...@widodh.nl>
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 <da...@gmail.com>
> Sent: 03 August 2026 10:48 AM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Cc: Wido den Hollander <wi...@widodh.nl>
> 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
> <de...@cloudstack.apache.org> 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
>> - 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
>>
>> 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
>> - 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
>> - 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
>> - 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://github.com/apache/cloudstack/discussions/8970
>> - Dec 2024 - CloudStack 5? (Rene Moser): reopened the same question.
>> 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
>> - 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
>> - Sep 2025 - [LTS] Extend LTS support to 24 months: adjacent, explicitly
>> scoped away from the versioning scheme.
>> https://lists.apache.org/thread/fkl74js7vxml9c29jqmhl2ctsxsq868o
>
>
>
> --
> Daan
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Wido den Hollander via dev <de...@cloudstack.apache.org>.
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 <da...@gmail.com>
> Sent: 03 August 2026 10:48 AM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Cc: Wido den Hollander <wi...@widodh.nl>
> 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
> <de...@cloudstack.apache.org> 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
>> - 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
>>
>> 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
>> - 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
>> - 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
>> - 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://github.com/apache/cloudstack/discussions/8970
>> - Dec 2024 - CloudStack 5? (Rene Moser): reopened the same question.
>> 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
>> - 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
>> - Sep 2025 - [LTS] Extend LTS support to 24 months: adjacent, explicitly
>> scoped away from the versioning scheme.
>> https://lists.apache.org/thread/fkl74js7vxml9c29jqmhl2ctsxsq868o
>
>
>
> --
> Daan
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Paul Angus via dev <de...@cloudstack.apache.org>.
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.
Kind regards
Paul Angus
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: 03 August 2026 10:48 AM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Cc: Wido den Hollander <wi...@widodh.nl>
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
<de...@cloudstack.apache.org> 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
> - 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
>
> 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
> - 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
> - 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
> - 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://github.com/apache/cloudstack/discussions/8970
> - Dec 2024 - CloudStack 5? (Rene Moser): reopened the same question.
> 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
> - 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
> - Sep 2025 - [LTS] Extend LTS support to 24 months: adjacent, explicitly
> scoped away from the versioning scheme.
> https://lists.apache.org/thread/fkl74js7vxml9c29jqmhl2ctsxsq868o
--
Daan
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Wido den Hollander via dev <de...@cloudstack.apache.org>.
Op 03-08-2026 om 11:48 schreef Daan Hoogland:
> I like ;)
>
:-)
> On Mon, Aug 3, 2026 at 11:37 AM Wido den Hollander via dev
> <de...@cloudstack.apache.org> 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 could stick with it as-is, but only remove the "4". That's my main
concern, that prefix of the "4" has to be dropped and this has been
proposed many times.
Nothing else changes, the 4 just goes away. Completely happy with that.
Wido
>
>> 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
>> - 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
>>
>> 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
>> - 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
>> - 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
>> - 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://github.com/apache/cloudstack/discussions/8970
>> - Dec 2024 - CloudStack 5? (Rene Moser): reopened the same question.
>> 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
>> - 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
>> - Sep 2025 - [LTS] Extend LTS support to 24 months: adjacent, explicitly
>> scoped away from the versioning scheme.
>> https://lists.apache.org/thread/fkl74js7vxml9c29jqmhl2ctsxsq868o
>
>
>
Re: [DISCUSS] Versioning of CloudStack in 2027 and beyond
Posted by Daan Hoogland <da...@gmail.com>.
I like ;)
On Mon, Aug 3, 2026 at 11:37 AM Wido den Hollander via dev
<de...@cloudstack.apache.org> 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
> - 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
>
> 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
> - 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
> - 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
> - 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://github.com/apache/cloudstack/discussions/8970
> - Dec 2024 - CloudStack 5? (Rene Moser): reopened the same question.
> 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
> - 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
> - Sep 2025 - [LTS] Extend LTS support to 24 months: adjacent, explicitly
> scoped away from the versioning scheme.
> https://lists.apache.org/thread/fkl74js7vxml9c29jqmhl2ctsxsq868o
--
Daan