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

Reply via email to