Question does stand, indeed (if we want to follow the "year" numbering) Let's have a clear plan - @Wido den Hollander <[email protected]> - 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 < [email protected]> 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 <[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 > > > > -- Andrija Panić
