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