+1 for dropping the 4. I don't really mind whether we go the Ubuntu style route or not, but either way will be positive for the project IMO.
In terms of João's concerns about API changes et al, the way I've seen this handled is having a versioning of the API, so the caller can specify (within reason) the version they want. This helps deal with breaking changes/new features. This may also mean creating a new endpoint if the changes are significant enough that a purely versioned endpoint won't suffice. -Si On Fri, Aug 14, 2026 at 7:41 AM Kiran Chavala <[email protected]> wrote: > Hi All > > +1 to dropping the "4" and also > > +1 to Rohit's idea to follow the naming convention of "YY.MM.XX" as it's > an easy way to identify the release date > > I generally like the way Ubuntu does its releases, > > https://ubuntu.com/project/docs/release-team/list-of-releases/ > > Regards > Kiran Chvala > > On 2026/08/14 11:02:51 Rohit Yadav via dev wrote: > > *typo in the example; non-LTS can be YY.04.XX ... > > > > Regards, > > Rohit Yadav > > Founder, ScaleNinja > > > > ScaleNinja Software LLP is incorporated in India. This email and any > > attachments to it may be confidential and are intended solely for the use > > of the individual to whom it is addressed. Any views or opinions > expressed > > are solely those of the author and do not necessarily represent those of > > ScaleNinja or related companies. If you are not the intended recipient of > > this email, you must neither take any action based upon its contents, nor > > copy or show it to anyone. Please contact the sender if you believe you > > have received this email in error. > > > > > > On Fri, 14 Aug 2026 at 16:31, Rohit Yadav <[email protected]> wrote: > > > > > IMO such marketing/product version renaming/rebranding will only last > 1-2 > > > cycles, until that becomes boring/normal again; so I don't have any > > > specific preference and I don't think this gains any mileage. > > > > > > To throw another idea in the spanner, moving to a release year/month in > > > the version makes more sense and makes it easier to remember. A lot of > > > products and projects are adopting that --- instead of 24.x.y; a > release > > > version can follow YY.MM.XX format, where YY Is the year, MM is the > month > > > and XX is the build/security release number that starts with 0 & > increments > > > (& there is no separate increment to track for security releases). > > > > > > The project can target at least two major releases a year, as examples > -- > > > one (or more) being non-LTS; LTS can be YY.04.XX and one being LTS > > > YY.10.XX (assuming release cadence happens in April & Oct every year). > > > > > > So, the next release can be CloudStack 26.10.0 (if released in 2026, > Oct) > > > - easy to read and make sense to me. Even in future when a > > > minor/maintenance release happens it would be easier to guess for > users the > > > maintenance release is for the major ACS release made in the YY.MM > > > release. > > > > > > Regards, > > > Rohit Yadav > > > Founder, ScaleNinja > > > > > > ScaleNinja Software LLP is incorporated in India. This email and any > > > attachments to it may be confidential and are intended solely for the > use > > > of the individual to whom it is addressed. Any views or opinions > expressed > > > are solely those of the author and do not necessarily represent those > of > > > ScaleNinja or related companies. If you are not the intended recipient > of > > > this email, you must neither take any action based upon its contents, > nor > > > copy or show it to anyone. Please contact the sender if you believe you > > > have received this email in error. > > > > > > > > > On Fri, 14 Aug 2026 at 13:40, Abhishek Kumar <[email protected]> > wrote: > > > > > >> +0 > > >> > > >> I don't have a strong inclination either way. > > >> If we decide to drop it, it may take some effort to update the > > >> documentation, the website, etc. At some point, we may have to > > >> inventory all those changes, preferably well before the actual release > > >> happens. > > >> > > >> Regards, > > >> Abhishek > > >> > > >> On Fri, 14 Aug 2026 at 12:37, Wido den Hollander via dev > > >> <[email protected]> wrote: > > >> > > > >> > Hi all, > > >> > > > >> > Following the discussion in the proposal thread [1], I would like to > > >> > call a vote on changing the version naming of Apache CloudStack. > > >> > > > >> > What is being proposed: > > >> > > > >> > - 4.23 is released as planned, using the current naming scheme. > > >> > - The release that would have been 4.24 is instead released as 24, > i.e. > > >> > 24.0.0 > > >> > - From there we continue releasing exactly as we do today, only > without > > >> > the "4." prefix. Subsequent feature releases become 25, 26, etc., > and > > >> > maintenance releases on the 24 branch become 24.1.0, 24.2.0, and so > on. > > >> > > > >> > This is a change to the version naming only. It does **not** change > our > > >> > release cadence, our LTS policy, our branching and release process, > or > > >> > our backwards-compatibility guarantees. Dropping the "4." is not a > > >> > signal that 24 will break APIs or introduce disruptive changes. > > >> > > > >> > The leading "4." has not carried any meaning for many years. We have > > >> > never incremented it, and we do not expect to, so in practice the > number > > >> > that identifies a release is the second component. Dropping the > prefix > > >> > makes the version we all actually use in conversation, docs, > packages > > >> > and branch names the version we publish, and it removes the > recurring > > >> > confusion about what a major version bump would mean for us. > > >> > > > >> > If we decide this in the coming weeks, we can announce and explain > the > > >> > change at the CloudStack Collaboration Conference in November 2026. > That > > >> > gives us a single moment where we can lay out to the whole > community, in > > >> > person, what changes and, more importantly, what does not change. A > > >> > version naming change is exactly the kind of thing that generates > > >> > uncertainty among operators and users if it only appears in a > release > > >> > note, and CCC gives us the opportunity to get ahead of that and > answer > > >> > questions directly. Deciding now also means 24 can be prepared and > > >> > communicated as such from the start of its development cycle, rather > > >> > than being renamed halfway through. > > >> > > > >> > Please vote: > > >> > > > >> > [ ] +1 Drop the "4" prefix, starting with release 24 > > >> > [ ] +0 No opinion > > >> > [ ] -1 Do not adopt (please state your reasoning) > > >> > > > >> > Looking forward to the votes! > > >> > > > >> > The vote is open for 7 days and will close on Friday 21 August 2026 > at > > >> > 12:00 UTC. Votes from PMC members are binding, but everybody in the > > >> > community is welcome and encouraged to vote and to share their view. > > >> > > > >> > Wido > > >> > > > >> > [1] > https://lists.apache.org/thread/j2ofomb32kms1jh6772p7qobrt68rygc > > >> > > >> > > >
