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