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 <[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 > - 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
