Re: 4.23.0 Release plan

[Wei ZHOU <us...@gmail.com>]

Hi All,

After discussing this with several community members, we decided to keep
the 4.23 open for one more week so that the outstanding PRs currently under
testing or final review can be included in the 4.23.0.0 release.

The updated timeline for 4.23.0 is as follows:

   - *Until July 10, 2026:* Accept new features, bug fixes, and
   improvements. Features that are not ready to be merged by then will be
   moved to 4.24.0.
   - *July 11, 2026:* Freeze the main branch. From this point onward, only
   critical/blocker fixes will be accepted.
   - *July 13, 2026, or once all blocker and critical issues have been
   resolved (whichever is later):* Cut RC1 and begin the voting process.


Thanks everyone for the understanding.

Kind regards,
Wei


On Thu, May 21, 2026 at 2:47 PM Fabricio Duarte Junior <fa...@apache.org>
wrote:

> (forwarding from users@ to dev@)
> Hey all,
>
> After evaluating the current state and the remaining work for 4.23.0, we
> have decided to
> postpone the release by another month. This is to ensure we can deliver a
> more complete,
> polished, and well tested version.
>
> This postponement was primarily due to the following factors:
>
> - A good portion of the features and enhancements planned for 4.23.0 [1]
> are still under
> development.
> - We had some delays in addressing security issues from previous cycles.
> - There is a considerable number of security issues that we intend to
> solve on this release.
> - We still have a significant number of open pull requests waiting for
> review and testing.
>
> Hence, the updated timeline for 4.23.0 is the following:
>
> - Until July 3rd, 2026: accept new features, bug fixes, and improvements.
> Features that are not
> yet ready for merge will be moved to 4.24.0.
> - July 4th, 2026: freeze the main branch. From this point onward, only
> critical/blocker fixes will be
> accepted.
> - July 6th, 2026, or once all blocker/critical/security issues are
> resolved (whichever is later): cut
> RC1 and start the voting process.
>
> We kindly ask for the community's support in reviewing and testing the PRs
> marked for 4.23.0.
> Additional help in these will be essential to keep the schedule on track.
>
> Once again, thanks everyone for the understanding.
>
> On 2026/04/07 19:44:17 Wei ZHOU wrote:
> > Hi all,
> >
> > Due to several factors - such as the number of ongoing improvements and
> new
> > features, the significant QA effort required, and pending security
> issues -
> > we have decided to adjust the timeline. All dates will be postponed by
> one
> > month.
> >
> > The updated timeline of 4.23.0.0 release is as follows:
> >
> >    - *Until June 1st, 2026*: Accept new features, bug fixes, and
> >    improvements
> >    - *June 2nd, 2026*: Freeze the main branch. From this point onward,
> only
> >    critical/blocker fixes will be accepted
> >    - *June 3rd, 2026*, or once all blocker/critical/security issues are
> >    resolved (whichever is later): Cut RC1 and start the voting process
> (allow
> >    1-3 weeks for additional RCs if necessary)
> >
> >
> > Thanks for your understanding and collaboration.
> >
> >
> > Kind regards,
> > Wei & Fabricio
> >
> >
> >
> >
> > On Tue, Feb 3, 2026 at 9:11 AM Wei ZHOU <us...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > We are planning to work on a CloudStack 4.23.0 release.
> > >
> > > CloudStack 4.23.0 will be a Regular release [1], which introduces new
> > > features
> > > and enhancements.  It is targeted for users who require the newest
> > > features as
> > > early as possible and are able to upgrade when the releases are
> available.
> > >
> > > As discussed [2], I'll serve as the RM for the 4.23.0 release. Fabricio
> > > Duarte will
> > > act as the co-RM, assisting with triage, reviews, testing, merges, etc
> and
> > > release work.
> > >
> > > The timeline for this would be the following (Proposed by Fabricio,
> > > thanks):
> > >
> > > - Until May 3rd 2026: accept new features, bug fixes and improvements.
> > > - May 4th 2026: freeze the main branch. From this point, we would only
> > > accept
> > > critical/blocker fixes.
> > > - May 11th 2026: cut RC1 and start the vote (1-3 weeks to work on the
> next
> > > RCs if necessary).
> > >
> > > All open issues and PRs targeted for this release are tracked in the
> > > 4.23.0
> > > release milestone [3]. The design document of some features can be
> found
> > > at
> > >
> > >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.23+Design+Documents
> > >
> > > Please ping us (@weizhouapache or @winterhazel) on your PRs and issues
> > > that
> > > are to be included in 4.23.0 on Github. Please let us know if you have
> any
> > > questions.
> > >
> > >
> > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> > > [2] https://lists.apache.org/thread/z7n339vcdym9f494ngb5pkzlxx8mjf2n
> > > [3] https://github.com/apache/cloudstack/milestone/42
> > >
> > >
> > > Kind regards,
> > > Wei
> > >
> > >
> >
>

Re: 4.23.0 Release plan

[Wei ZHOU <us...@gmail.com>]

Hi Abhishek,

Thanks for sharing your thoughts. I agree that we should continue to think
about how to improve the release process.

For 4.23.0, I was quite ambitious and initially added a large number of
pull requests and issues to the milestone. Some of them were also moved
from the 4.22.0 milestone after the 4.22 release.

When I reviewed the milestone on 29th June 2026, there were still more than
50 pull requests remaining. Since we were approaching the code freeze, I
gradually moved some items to 4.24.0 due to inactivity, lack of review or
updates. For bug fixes that were not critical for 4.23.0, I moved some to
4.22.2 or 4.20.4. I notified authors for some PRs, although I realize I did
not do so consistently for every case.

I would like to clarify that being included in a milestone does not
necessarily mean a PR will finally be included in the release. Similarly,
once a PR is moved out of the milestone, it does not mean the contribution
is rejected; it simply means it is unlikely to make this specific release.
If a PR is ready for merge and meets the merge criteria, we will of course
consider it regardless of whether it is currently listed in the milestone.
In my view, the milestone is mainly a management tool for the release
manager (some RMs may use GitHub projects or other approaches instead).

Fabricio and I have shared and updated the release timeline through the
dev/users mailing lists. If contributors believe their PRs should be
included in the release, I would encourage them to proactively follow up
and help drive the required reviews, testing, and updates. We are happy to
help unblock issues, but ultimately the PR author is the best person to
push their contribution forward.

I also want to appreciate the NetApp contributors, who have been very
active in driving their PRs toward inclusion in the 4.23.0 release.

For future releases, I think your suggestion about keeping items unplanned
initially and only moving them into the release scope after they are
evaluated is worth discussing. It may help set clearer expectations and
reduce surprises closer to the release date.


Kind regards,

Wei



On Thu, Jul 16, 2026 at 4:18 PM Abhishek Kumar <ab...@gmail.com>
wrote:

> Hi Wei,
>
> I uderstand the special cases and RM's discretion. My major point of
> concern is can we be less conservative in non-LTS releases to allow
> contributions from individuals who in most cases may not have support of
> peer reviews and manual QA.
>
> I can surely share some examples in private which could have been included.
> Maybe it would be better to move on and focus on the release for now.
>
> I do have a suggestion maybe for future, we keep all items as unplanned at
> the time release planning and only consider adding those items which
> genuinely seem fit to be included. This will make onus fall on the
> contributor to ask RM for their contribution to be included. Currently, one
> may see his/her PR present in the milestone early on but then suddenly
> around release they get moved out.
>
> Regards,
>
>
> Abhishek Kumar
>
> On Thu, 16 Jul, 2026, 13:45 Wei ZHOU, <us...@gmail.com> wrote:
>
> > Hi Abhishek,
> >
> > Thanks for the feedback. I understand your point, and I agree that we
> > should strive to be more transparent when PRs are moved out of a
> milestone.
> >
> > The PR you mentioned is a bit of a special case. We were very close to
> the
> > code freeze, the change itself was small and low impact, and it had at
> > least been tested by the author. It was also not the only exception -
> there
> > were other small PRs merged on the last day before the code freeze under
> > similar circumstances. Ultimately, these decisions rely on the release
> > managers' experience and judgment, taking into account the scope of the
> > change, the potential risk, the level of review, and the time remaining
> > before the release. The smoke test results on the 4.23 health check PR on
> > various hypervisors look fine. That said, I agree we should try to avoid
> > these last-minute exceptions in the future.
> >
> > Out of curiosity, are there any specific PRs that you think should have
> > made it into the 4.23 release? It would be useful to discuss those
> examples
> > and see whether we could improve the process for future releases.
> > Kind regards,
> > Wei
> >
> >
> > On Thu, Jul 16, 2026 at 9:37 AM Abhishek Kumar <sh...@apache.org>
> > wrote:
> >
> > > Thanks Wei. I understand the constraints, but overall, I feel it is
> > > all about subjectivity and convenience.
> > > Just for an example, this PR
> > > https://github.com/apache/cloudstack/pull/13613 was merged within 2
> > > hours of creation. Approved by one of the RMs for merging. No
> > > integration tests (though they wouldn't help much in this case). I
> > > don't see any manual test reported in the PR either.
> > > Definitely, we can not include all PRs, but I feel that when they are
> > > moved out of a milestone, it would be better to give some reason.
> > > Maybe it is my problem and my expectations are a bit high around this.
> > >
> > > Regards,
> > > Abhishek
> > >
>

Re: 4.23.0 Release plan

[Wei ZHOU <us...@gmail.com>]

Hi Abhishek,

Thanks for sharing your thoughts. I agree that we should continue to think
about how to improve the release process.

For 4.23.0, I was quite ambitious and initially added a large number of
pull requests and issues to the milestone. Some of them were also moved
from the 4.22.0 milestone after the 4.22 release.

When I reviewed the milestone on 29th June 2026, there were still more than
50 pull requests remaining. Since we were approaching the code freeze, I
gradually moved some items to 4.24.0 due to inactivity, lack of review or
updates. For bug fixes that were not critical for 4.23.0, I moved some to
4.22.2 or 4.20.4. I notified authors for some PRs, although I realize I did
not do so consistently for every case.

I would like to clarify that being included in a milestone does not
necessarily mean a PR will finally be included in the release. Similarly,
once a PR is moved out of the milestone, it does not mean the contribution
is rejected; it simply means it is unlikely to make this specific release.
If a PR is ready for merge and meets the merge criteria, we will of course
consider it regardless of whether it is currently listed in the milestone.
In my view, the milestone is mainly a management tool for the release
manager (some RMs may use GitHub projects or other approaches instead).

Fabricio and I have shared and updated the release timeline through the
dev/users mailing lists. If contributors believe their PRs should be
included in the release, I would encourage them to proactively follow up
and help drive the required reviews, testing, and updates. We are happy to
help unblock issues, but ultimately the PR author is the best person to
push their contribution forward.

I also want to appreciate the NetApp contributors, who have been very
active in driving their PRs toward inclusion in the 4.23.0 release.

For future releases, I think your suggestion about keeping items unplanned
initially and only moving them into the release scope after they are
evaluated is worth discussing. It may help set clearer expectations and
reduce surprises closer to the release date.


Kind regards,

Wei



On Thu, Jul 16, 2026 at 4:18 PM Abhishek Kumar <ab...@gmail.com>
wrote:

> Hi Wei,
>
> I uderstand the special cases and RM's discretion. My major point of
> concern is can we be less conservative in non-LTS releases to allow
> contributions from individuals who in most cases may not have support of
> peer reviews and manual QA.
>
> I can surely share some examples in private which could have been included.
> Maybe it would be better to move on and focus on the release for now.
>
> I do have a suggestion maybe for future, we keep all items as unplanned at
> the time release planning and only consider adding those items which
> genuinely seem fit to be included. This will make onus fall on the
> contributor to ask RM for their contribution to be included. Currently, one
> may see his/her PR present in the milestone early on but then suddenly
> around release they get moved out.
>
> Regards,
>
>
> Abhishek Kumar
>
> On Thu, 16 Jul, 2026, 13:45 Wei ZHOU, <us...@gmail.com> wrote:
>
> > Hi Abhishek,
> >
> > Thanks for the feedback. I understand your point, and I agree that we
> > should strive to be more transparent when PRs are moved out of a
> milestone.
> >
> > The PR you mentioned is a bit of a special case. We were very close to
> the
> > code freeze, the change itself was small and low impact, and it had at
> > least been tested by the author. It was also not the only exception -
> there
> > were other small PRs merged on the last day before the code freeze under
> > similar circumstances. Ultimately, these decisions rely on the release
> > managers' experience and judgment, taking into account the scope of the
> > change, the potential risk, the level of review, and the time remaining
> > before the release. The smoke test results on the 4.23 health check PR on
> > various hypervisors look fine. That said, I agree we should try to avoid
> > these last-minute exceptions in the future.
> >
> > Out of curiosity, are there any specific PRs that you think should have
> > made it into the 4.23 release? It would be useful to discuss those
> examples
> > and see whether we could improve the process for future releases.
> > Kind regards,
> > Wei
> >
> >
> > On Thu, Jul 16, 2026 at 9:37 AM Abhishek Kumar <sh...@apache.org>
> > wrote:
> >
> > > Thanks Wei. I understand the constraints, but overall, I feel it is
> > > all about subjectivity and convenience.
> > > Just for an example, this PR
> > > https://github.com/apache/cloudstack/pull/13613 was merged within 2
> > > hours of creation. Approved by one of the RMs for merging. No
> > > integration tests (though they wouldn't help much in this case). I
> > > don't see any manual test reported in the PR either.
> > > Definitely, we can not include all PRs, but I feel that when they are
> > > moved out of a milestone, it would be better to give some reason.
> > > Maybe it is my problem and my expectations are a bit high around this.
> > >
> > > Regards,
> > > Abhishek
> > >
>

Re: 4.23.0 Release plan

[Abhishek Kumar <ab...@gmail.com>]

Hi Wei,

I uderstand the special cases and RM's discretion. My major point of
concern is can we be less conservative in non-LTS releases to allow
contributions from individuals who in most cases may not have support of
peer reviews and manual QA.

I can surely share some examples in private which could have been included.
Maybe it would be better to move on and focus on the release for now.

I do have a suggestion maybe for future, we keep all items as unplanned at
the time release planning and only consider adding those items which
genuinely seem fit to be included. This will make onus fall on the
contributor to ask RM for their contribution to be included. Currently, one
may see his/her PR present in the milestone early on but then suddenly
around release they get moved out.

Regards,


Abhishek Kumar

On Thu, 16 Jul, 2026, 13:45 Wei ZHOU, <us...@gmail.com> wrote:

> Hi Abhishek,
>
> Thanks for the feedback. I understand your point, and I agree that we
> should strive to be more transparent when PRs are moved out of a milestone.
>
> The PR you mentioned is a bit of a special case. We were very close to the
> code freeze, the change itself was small and low impact, and it had at
> least been tested by the author. It was also not the only exception - there
> were other small PRs merged on the last day before the code freeze under
> similar circumstances. Ultimately, these decisions rely on the release
> managers' experience and judgment, taking into account the scope of the
> change, the potential risk, the level of review, and the time remaining
> before the release. The smoke test results on the 4.23 health check PR on
> various hypervisors look fine. That said, I agree we should try to avoid
> these last-minute exceptions in the future.
>
> Out of curiosity, are there any specific PRs that you think should have
> made it into the 4.23 release? It would be useful to discuss those examples
> and see whether we could improve the process for future releases.
> Kind regards,
> Wei
>
>
> On Thu, Jul 16, 2026 at 9:37 AM Abhishek Kumar <sh...@apache.org>
> wrote:
>
> > Thanks Wei. I understand the constraints, but overall, I feel it is
> > all about subjectivity and convenience.
> > Just for an example, this PR
> > https://github.com/apache/cloudstack/pull/13613 was merged within 2
> > hours of creation. Approved by one of the RMs for merging. No
> > integration tests (though they wouldn't help much in this case). I
> > don't see any manual test reported in the PR either.
> > Definitely, we can not include all PRs, but I feel that when they are
> > moved out of a milestone, it would be better to give some reason.
> > Maybe it is my problem and my expectations are a bit high around this.
> >
> > Regards,
> > Abhishek
> >
> > On Thu, 16 Jul 2026 at 12:29, Wei ZHOU <us...@gmail.com> wrote:
> > >
> > > Hi Abhishek,
> > >
> > > Thanks for sharing your thoughts. I understand your concern, and I
> agree
> > > that we should continue looking for ways to reduce the growing PR
> > backlog.
> > >
> > > One thing I'd like to clarify is that 4.23 is a regular feature
> release,
> > > with a primary focus on new features and improvements. Most bug-fix PRs
> > are
> > > instead targeted for the 4.22.2.0 or 4.20.4.0 milestones, which are the
> > > next LTS releases.
> > >
> > > Regarding the PRs that were moved out of the 4.23.0 milestone, the main
> > > reason was not necessarily the risk of the changes themselves. Many of
> > them
> > > were simply not ready for review and testing before the code freeze.
> > > According to our merge policy, every PR must be adequately reviewed and
> > > tested before it can be merged. If a PR is still work in progress,
> > awaiting
> > > review, or has not yet been sufficiently validated, it cannot
> > realistically
> > > be included in the release.
> > >
> > > The community also has limited QA resources. This is especially
> > challenging
> > > for new features and large improvements, which typically require
> > > considerably more effort to review and test than bug fixes. As a
> result,
> > > some PRs had to be deferred even though they are valuable additions.
> The
> > > deferred PRs have been moved to the 4.24.0 milestone:
> > >
> >
> https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.24.0
> > >
> > > Hopefully, this provides enough visibility for authors and reviewers to
> > > continue working on them early in the next development cycle.
> > >
> > > I agree that reducing the PR backlog is important, and I think the best
> > way
> > > to achieve that is to encourage PR authors to get their changes ready
> for
> > > review and testing earlier in the release cycle, while also attracting
> > more
> > > reviewers and testers from the community.
> > >
> > > Thanks again for raising the discussion.
> > >
> > >
> > >
> > > Kind regards,
> > >
> > > Wei
> > >
> > >
> > >
> >
>

Re: 4.23.0 Release plan

[Abhishek Kumar <ab...@gmail.com>]

Hi Wei,

I uderstand the special cases and RM's discretion. My major point of
concern is can we be less conservative in non-LTS releases to allow
contributions from individuals who in most cases may not have support of
peer reviews and manual QA.

I can surely share some examples in private which could have been included.
Maybe it would be better to move on and focus on the release for now.

I do have a suggestion maybe for future, we keep all items as unplanned at
the time release planning and only consider adding those items which
genuinely seem fit to be included. This will make onus fall on the
contributor to ask RM for their contribution to be included. Currently, one
may see his/her PR present in the milestone early on but then suddenly
around release they get moved out.

Regards,


Abhishek Kumar

On Thu, 16 Jul, 2026, 13:45 Wei ZHOU, <us...@gmail.com> wrote:

> Hi Abhishek,
>
> Thanks for the feedback. I understand your point, and I agree that we
> should strive to be more transparent when PRs are moved out of a milestone.
>
> The PR you mentioned is a bit of a special case. We were very close to the
> code freeze, the change itself was small and low impact, and it had at
> least been tested by the author. It was also not the only exception - there
> were other small PRs merged on the last day before the code freeze under
> similar circumstances. Ultimately, these decisions rely on the release
> managers' experience and judgment, taking into account the scope of the
> change, the potential risk, the level of review, and the time remaining
> before the release. The smoke test results on the 4.23 health check PR on
> various hypervisors look fine. That said, I agree we should try to avoid
> these last-minute exceptions in the future.
>
> Out of curiosity, are there any specific PRs that you think should have
> made it into the 4.23 release? It would be useful to discuss those examples
> and see whether we could improve the process for future releases.
> Kind regards,
> Wei
>
>
> On Thu, Jul 16, 2026 at 9:37 AM Abhishek Kumar <sh...@apache.org>
> wrote:
>
> > Thanks Wei. I understand the constraints, but overall, I feel it is
> > all about subjectivity and convenience.
> > Just for an example, this PR
> > https://github.com/apache/cloudstack/pull/13613 was merged within 2
> > hours of creation. Approved by one of the RMs for merging. No
> > integration tests (though they wouldn't help much in this case). I
> > don't see any manual test reported in the PR either.
> > Definitely, we can not include all PRs, but I feel that when they are
> > moved out of a milestone, it would be better to give some reason.
> > Maybe it is my problem and my expectations are a bit high around this.
> >
> > Regards,
> > Abhishek
> >
> > On Thu, 16 Jul 2026 at 12:29, Wei ZHOU <us...@gmail.com> wrote:
> > >
> > > Hi Abhishek,
> > >
> > > Thanks for sharing your thoughts. I understand your concern, and I
> agree
> > > that we should continue looking for ways to reduce the growing PR
> > backlog.
> > >
> > > One thing I'd like to clarify is that 4.23 is a regular feature
> release,
> > > with a primary focus on new features and improvements. Most bug-fix PRs
> > are
> > > instead targeted for the 4.22.2.0 or 4.20.4.0 milestones, which are the
> > > next LTS releases.
> > >
> > > Regarding the PRs that were moved out of the 4.23.0 milestone, the main
> > > reason was not necessarily the risk of the changes themselves. Many of
> > them
> > > were simply not ready for review and testing before the code freeze.
> > > According to our merge policy, every PR must be adequately reviewed and
> > > tested before it can be merged. If a PR is still work in progress,
> > awaiting
> > > review, or has not yet been sufficiently validated, it cannot
> > realistically
> > > be included in the release.
> > >
> > > The community also has limited QA resources. This is especially
> > challenging
> > > for new features and large improvements, which typically require
> > > considerably more effort to review and test than bug fixes. As a
> result,
> > > some PRs had to be deferred even though they are valuable additions.
> The
> > > deferred PRs have been moved to the 4.24.0 milestone:
> > >
> >
> https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.24.0
> > >
> > > Hopefully, this provides enough visibility for authors and reviewers to
> > > continue working on them early in the next development cycle.
> > >
> > > I agree that reducing the PR backlog is important, and I think the best
> > way
> > > to achieve that is to encourage PR authors to get their changes ready
> for
> > > review and testing earlier in the release cycle, while also attracting
> > more
> > > reviewers and testers from the community.
> > >
> > > Thanks again for raising the discussion.
> > >
> > >
> > >
> > > Kind regards,
> > >
> > > Wei
> > >
> > >
> > >
> >
>

Re: 4.23.0 Release plan

[Wei ZHOU <us...@gmail.com>]

Hi Abhishek,

Thanks for the feedback. I understand your point, and I agree that we
should strive to be more transparent when PRs are moved out of a milestone.

The PR you mentioned is a bit of a special case. We were very close to the
code freeze, the change itself was small and low impact, and it had at
least been tested by the author. It was also not the only exception - there
were other small PRs merged on the last day before the code freeze under
similar circumstances. Ultimately, these decisions rely on the release
managers' experience and judgment, taking into account the scope of the
change, the potential risk, the level of review, and the time remaining
before the release. The smoke test results on the 4.23 health check PR on
various hypervisors look fine. That said, I agree we should try to avoid
these last-minute exceptions in the future.

Out of curiosity, are there any specific PRs that you think should have
made it into the 4.23 release? It would be useful to discuss those examples
and see whether we could improve the process for future releases.
Kind regards,
Wei


On Thu, Jul 16, 2026 at 9:37 AM Abhishek Kumar <sh...@apache.org> wrote:

> Thanks Wei. I understand the constraints, but overall, I feel it is
> all about subjectivity and convenience.
> Just for an example, this PR
> https://github.com/apache/cloudstack/pull/13613 was merged within 2
> hours of creation. Approved by one of the RMs for merging. No
> integration tests (though they wouldn't help much in this case). I
> don't see any manual test reported in the PR either.
> Definitely, we can not include all PRs, but I feel that when they are
> moved out of a milestone, it would be better to give some reason.
> Maybe it is my problem and my expectations are a bit high around this.
>
> Regards,
> Abhishek
>
> On Thu, 16 Jul 2026 at 12:29, Wei ZHOU <us...@gmail.com> wrote:
> >
> > Hi Abhishek,
> >
> > Thanks for sharing your thoughts. I understand your concern, and I agree
> > that we should continue looking for ways to reduce the growing PR
> backlog.
> >
> > One thing I'd like to clarify is that 4.23 is a regular feature release,
> > with a primary focus on new features and improvements. Most bug-fix PRs
> are
> > instead targeted for the 4.22.2.0 or 4.20.4.0 milestones, which are the
> > next LTS releases.
> >
> > Regarding the PRs that were moved out of the 4.23.0 milestone, the main
> > reason was not necessarily the risk of the changes themselves. Many of
> them
> > were simply not ready for review and testing before the code freeze.
> > According to our merge policy, every PR must be adequately reviewed and
> > tested before it can be merged. If a PR is still work in progress,
> awaiting
> > review, or has not yet been sufficiently validated, it cannot
> realistically
> > be included in the release.
> >
> > The community also has limited QA resources. This is especially
> challenging
> > for new features and large improvements, which typically require
> > considerably more effort to review and test than bug fixes. As a result,
> > some PRs had to be deferred even though they are valuable additions.  The
> > deferred PRs have been moved to the 4.24.0 milestone:
> >
> https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.24.0
> >
> > Hopefully, this provides enough visibility for authors and reviewers to
> > continue working on them early in the next development cycle.
> >
> > I agree that reducing the PR backlog is important, and I think the best
> way
> > to achieve that is to encourage PR authors to get their changes ready for
> > review and testing earlier in the release cycle, while also attracting
> more
> > reviewers and testers from the community.
> >
> > Thanks again for raising the discussion.
> >
> >
> >
> > Kind regards,
> >
> > Wei
> >
> >
> >
>

Re: 4.23.0 Release plan

[Wei ZHOU <us...@gmail.com>]

Hi Abhishek,

Thanks for the feedback. I understand your point, and I agree that we
should strive to be more transparent when PRs are moved out of a milestone.

The PR you mentioned is a bit of a special case. We were very close to the
code freeze, the change itself was small and low impact, and it had at
least been tested by the author. It was also not the only exception - there
were other small PRs merged on the last day before the code freeze under
similar circumstances. Ultimately, these decisions rely on the release
managers' experience and judgment, taking into account the scope of the
change, the potential risk, the level of review, and the time remaining
before the release. The smoke test results on the 4.23 health check PR on
various hypervisors look fine. That said, I agree we should try to avoid
these last-minute exceptions in the future.

Out of curiosity, are there any specific PRs that you think should have
made it into the 4.23 release? It would be useful to discuss those examples
and see whether we could improve the process for future releases.
Kind regards,
Wei


On Thu, Jul 16, 2026 at 9:37 AM Abhishek Kumar <sh...@apache.org> wrote:

> Thanks Wei. I understand the constraints, but overall, I feel it is
> all about subjectivity and convenience.
> Just for an example, this PR
> https://github.com/apache/cloudstack/pull/13613 was merged within 2
> hours of creation. Approved by one of the RMs for merging. No
> integration tests (though they wouldn't help much in this case). I
> don't see any manual test reported in the PR either.
> Definitely, we can not include all PRs, but I feel that when they are
> moved out of a milestone, it would be better to give some reason.
> Maybe it is my problem and my expectations are a bit high around this.
>
> Regards,
> Abhishek
>
> On Thu, 16 Jul 2026 at 12:29, Wei ZHOU <us...@gmail.com> wrote:
> >
> > Hi Abhishek,
> >
> > Thanks for sharing your thoughts. I understand your concern, and I agree
> > that we should continue looking for ways to reduce the growing PR
> backlog.
> >
> > One thing I'd like to clarify is that 4.23 is a regular feature release,
> > with a primary focus on new features and improvements. Most bug-fix PRs
> are
> > instead targeted for the 4.22.2.0 or 4.20.4.0 milestones, which are the
> > next LTS releases.
> >
> > Regarding the PRs that were moved out of the 4.23.0 milestone, the main
> > reason was not necessarily the risk of the changes themselves. Many of
> them
> > were simply not ready for review and testing before the code freeze.
> > According to our merge policy, every PR must be adequately reviewed and
> > tested before it can be merged. If a PR is still work in progress,
> awaiting
> > review, or has not yet been sufficiently validated, it cannot
> realistically
> > be included in the release.
> >
> > The community also has limited QA resources. This is especially
> challenging
> > for new features and large improvements, which typically require
> > considerably more effort to review and test than bug fixes. As a result,
> > some PRs had to be deferred even though they are valuable additions.  The
> > deferred PRs have been moved to the 4.24.0 milestone:
> >
> https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.24.0
> >
> > Hopefully, this provides enough visibility for authors and reviewers to
> > continue working on them early in the next development cycle.
> >
> > I agree that reducing the PR backlog is important, and I think the best
> way
> > to achieve that is to encourage PR authors to get their changes ready for
> > review and testing earlier in the release cycle, while also attracting
> more
> > reviewers and testers from the community.
> >
> > Thanks again for raising the discussion.
> >
> >
> >
> > Kind regards,
> >
> > Wei
> >
> >
> >
>

Re: 4.23.0 Release plan

[Abhishek Kumar <sh...@apache.org>]

Thanks Wei. I understand the constraints, but overall, I feel it is
all about subjectivity and convenience.
Just for an example, this PR
https://github.com/apache/cloudstack/pull/13613 was merged within 2
hours of creation. Approved by one of the RMs for merging. No
integration tests (though they wouldn't help much in this case). I
don't see any manual test reported in the PR either.
Definitely, we can not include all PRs, but I feel that when they are
moved out of a milestone, it would be better to give some reason.
Maybe it is my problem and my expectations are a bit high around this.

Regards,
Abhishek

On Thu, 16 Jul 2026 at 12:29, Wei ZHOU <us...@gmail.com> wrote:
>
> Hi Abhishek,
>
> Thanks for sharing your thoughts. I understand your concern, and I agree
> that we should continue looking for ways to reduce the growing PR backlog.
>
> One thing I'd like to clarify is that 4.23 is a regular feature release,
> with a primary focus on new features and improvements. Most bug-fix PRs are
> instead targeted for the 4.22.2.0 or 4.20.4.0 milestones, which are the
> next LTS releases.
>
> Regarding the PRs that were moved out of the 4.23.0 milestone, the main
> reason was not necessarily the risk of the changes themselves. Many of them
> were simply not ready for review and testing before the code freeze.
> According to our merge policy, every PR must be adequately reviewed and
> tested before it can be merged. If a PR is still work in progress, awaiting
> review, or has not yet been sufficiently validated, it cannot realistically
> be included in the release.
>
> The community also has limited QA resources. This is especially challenging
> for new features and large improvements, which typically require
> considerably more effort to review and test than bug fixes. As a result,
> some PRs had to be deferred even though they are valuable additions.  The
> deferred PRs have been moved to the 4.24.0 milestone:
> https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.24.0
>
> Hopefully, this provides enough visibility for authors and reviewers to
> continue working on them early in the next development cycle.
>
> I agree that reducing the PR backlog is important, and I think the best way
> to achieve that is to encourage PR authors to get their changes ready for
> review and testing earlier in the release cycle, while also attracting more
> reviewers and testers from the community.
>
> Thanks again for raising the discussion.
>
>
>
> Kind regards,
>
> Wei
>
>
>
>
>
> On Thu, Jul 16, 2026 at 8:42 AM Abhishek Kumar <sh...@apache.org> wrote:
>
> > Hi Wei and other RMs,
> >
> > Thank you for the update and for all the effort that has gone into
> > preparing the release.
> >
> > While it will be great to have a stable 4.23.0 release soon, I was a
> > little disappointed to see a number of self-contained PRs and changes
> > moved out of the 4.23.0 milestone without any accompanying rationale.
> > By "self-contained," I mean changes that are largely isolated and do
> > not affect major existing CloudStack components. Since 4.23.0 is a
> > non-LTS release, I had hoped it would provide an opportunity to
> > include such changes, even if they carry a bit more risk than what
> > we'd typically consider for an LTS release.
> >
> > We currently have a backlog of over 260 open PRs, and I'm concerned
> > that if we continue to take this approach, it will become increasingly
> > difficult to make meaningful progress in reducing that backlog.
> >
> > These are just my personal thoughts, and I fully appreciate the effort
> > that goes into balancing stability with feature delivery. Looking
> > forward to the new release and the many exciting features it will
> > bring.
> >
> > Regards,
> > Abhishek
> >
> > On Tue, 14 Jul 2026 at 22:46, Wei ZHOU <us...@gmail.com> wrote:
> > >
> > > Hi All,
> > >
> > > The code freeze for CloudStack 4.23.0.0 is now in effect. The main branch
> > > will remain frozen until the 4.23.0.0 release. From this point onward,
> > only
> > > blocker, critical, and security fixes will be accepted for merging.
> > >
> > > We will now focus on stabilizing the main branch and preparing the
> > > 4.23.0.0-RC1 release.
> > >
> > > Thanks everyone for your contributions and support in getting us to this
> > > milestone!
> > >
> > >
> > > Kind regards,
> > >
> > > Wei
> > >
> > >
> > >
> > > On Mon, Jul 6, 2026 at 3:19 PM Wei ZHOU <us...@gmail.com> wrote:
> > >
> > > > Hi All,
> > > >
> > > > After discussing this with several community members, we decided to
> > keep
> > > > the 4.23 open for one more week so that the outstanding PRs currently
> > under
> > > > testing or final review can be included in the 4.23.0.0 release.
> > > >
> > > > The updated timeline for 4.23.0 is as follows:
> > > >
> > > >    - *Until July 10, 2026:* Accept new features, bug fixes, and
> > > >    improvements. Features that are not ready to be merged by then will
> > be
> > > >    moved to 4.24.0.
> > > >    - *July 11, 2026:* Freeze the main branch. From this point onward,
> > > >    only critical/blocker fixes will be accepted.
> > > >    - *July 13, 2026, or once all blocker and critical issues have been
> > > >    resolved (whichever is later):* Cut RC1 and begin the voting
> > process.
> > > >
> > > >
> > > > Thanks everyone for the understanding.
> > > >
> > > > Kind regards,
> > > > Wei
> > > >
> > > >
> > > > On Thu, May 21, 2026 at 2:47 PM Fabricio Duarte Junior <
> > > > fabricio@apache.org> wrote:
> > > >
> > > >> (forwarding from users@ to dev@)
> > > >> Hey all,
> > > >>
> > > >> After evaluating the current state and the remaining work for 4.23.0,
> > we
> > > >> have decided to
> > > >> postpone the release by another month. This is to ensure we can
> > deliver a
> > > >> more complete,
> > > >> polished, and well tested version.
> > > >>
> > > >> This postponement was primarily due to the following factors:
> > > >>
> > > >> - A good portion of the features and enhancements planned for 4.23.0
> > [1]
> > > >> are still under
> > > >> development.
> > > >> - We had some delays in addressing security issues from previous
> > cycles.
> > > >> - There is a considerable number of security issues that we intend to
> > > >> solve on this release.
> > > >> - We still have a significant number of open pull requests waiting for
> > > >> review and testing.
> > > >>
> > > >> Hence, the updated timeline for 4.23.0 is the following:
> > > >>
> > > >> - Until July 3rd, 2026: accept new features, bug fixes, and
> > improvements.
> > > >> Features that are not
> > > >> yet ready for merge will be moved to 4.24.0.
> > > >> - July 4th, 2026: freeze the main branch. From this point onward, only
> > > >> critical/blocker fixes will be
> > > >> accepted.
> > > >> - July 6th, 2026, or once all blocker/critical/security issues are
> > > >> resolved (whichever is later): cut
> > > >> RC1 and start the voting process.
> > > >>
> > > >> We kindly ask for the community's support in reviewing and testing the
> > > >> PRs marked for 4.23.0.
> > > >> Additional help in these will be essential to keep the schedule on
> > track.
> > > >>
> > > >> Once again, thanks everyone for the understanding.
> > > >>
> > > >> On 2026/04/07 19:44:17 Wei ZHOU wrote:
> > > >> > Hi all,
> > > >> >
> > > >> > Due to several factors - such as the number of ongoing improvements
> > and
> > > >> new
> > > >> > features, the significant QA effort required, and pending security
> > > >> issues -
> > > >> > we have decided to adjust the timeline. All dates will be postponed
> > by
> > > >> one
> > > >> > month.
> > > >> >
> > > >> > The updated timeline of 4.23.0.0 release is as follows:
> > > >> >
> > > >> >    - *Until June 1st, 2026*: Accept new features, bug fixes, and
> > > >> >    improvements
> > > >> >    - *June 2nd, 2026*: Freeze the main branch. From this point
> > onward,
> > > >> only
> > > >> >    critical/blocker fixes will be accepted
> > > >> >    - *June 3rd, 2026*, or once all blocker/critical/security issues
> > are
> > > >> >    resolved (whichever is later): Cut RC1 and start the voting
> > process
> > > >> (allow
> > > >> >    1-3 weeks for additional RCs if necessary)
> > > >> >
> > > >> >
> > > >> > Thanks for your understanding and collaboration.
> > > >> >
> > > >> >
> > > >> > Kind regards,
> > > >> > Wei & Fabricio
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Tue, Feb 3, 2026 at 9:11 AM Wei ZHOU <us...@gmail.com>
> > wrote:
> > > >> >
> > > >> > > Hi all,
> > > >> > >
> > > >> > > We are planning to work on a CloudStack 4.23.0 release.
> > > >> > >
> > > >> > > CloudStack 4.23.0 will be a Regular release [1], which introduces
> > new
> > > >> > > features
> > > >> > > and enhancements.  It is targeted for users who require the newest
> > > >> > > features as
> > > >> > > early as possible and are able to upgrade when the releases are
> > > >> available.
> > > >> > >
> > > >> > > As discussed [2], I'll serve as the RM for the 4.23.0 release.
> > > >> Fabricio
> > > >> > > Duarte will
> > > >> > > act as the co-RM, assisting with triage, reviews, testing, merges,
> > > >> etc and
> > > >> > > release work.
> > > >> > >
> > > >> > > The timeline for this would be the following (Proposed by
> > Fabricio,
> > > >> > > thanks):
> > > >> > >
> > > >> > > - Until May 3rd 2026: accept new features, bug fixes and
> > improvements.
> > > >> > > - May 4th 2026: freeze the main branch. From this point, we would
> > only
> > > >> > > accept
> > > >> > > critical/blocker fixes.
> > > >> > > - May 11th 2026: cut RC1 and start the vote (1-3 weeks to work on
> > the
> > > >> next
> > > >> > > RCs if necessary).
> > > >> > >
> > > >> > > All open issues and PRs targeted for this release are tracked in
> > the
> > > >> > > 4.23.0
> > > >> > > release milestone [3]. The design document of some features can be
> > > >> found
> > > >> > > at
> > > >> > >
> > > >> > >
> > > >>
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.23+Design+Documents
> > > >> > >
> > > >> > > Please ping us (@weizhouapache or @winterhazel) on your PRs and
> > issues
> > > >> > > that
> > > >> > > are to be included in 4.23.0 on Github. Please let us know if you
> > > >> have any
> > > >> > > questions.
> > > >> > >
> > > >> > >
> > > >> > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> > > >> > > [2]
> > https://lists.apache.org/thread/z7n339vcdym9f494ngb5pkzlxx8mjf2n
> > > >> > > [3] https://github.com/apache/cloudstack/milestone/42
> > > >> > >
> > > >> > >
> > > >> > > Kind regards,
> > > >> > > Wei
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> >

Re: 4.23.0 Release plan

[Abhishek Kumar <sh...@apache.org>]

Thanks Wei. I understand the constraints, but overall, I feel it is
all about subjectivity and convenience.
Just for an example, this PR
https://github.com/apache/cloudstack/pull/13613 was merged within 2
hours of creation. Approved by one of the RMs for merging. No
integration tests (though they wouldn't help much in this case). I
don't see any manual test reported in the PR either.
Definitely, we can not include all PRs, but I feel that when they are
moved out of a milestone, it would be better to give some reason.
Maybe it is my problem and my expectations are a bit high around this.

Regards,
Abhishek

On Thu, 16 Jul 2026 at 12:29, Wei ZHOU <us...@gmail.com> wrote:
>
> Hi Abhishek,
>
> Thanks for sharing your thoughts. I understand your concern, and I agree
> that we should continue looking for ways to reduce the growing PR backlog.
>
> One thing I'd like to clarify is that 4.23 is a regular feature release,
> with a primary focus on new features and improvements. Most bug-fix PRs are
> instead targeted for the 4.22.2.0 or 4.20.4.0 milestones, which are the
> next LTS releases.
>
> Regarding the PRs that were moved out of the 4.23.0 milestone, the main
> reason was not necessarily the risk of the changes themselves. Many of them
> were simply not ready for review and testing before the code freeze.
> According to our merge policy, every PR must be adequately reviewed and
> tested before it can be merged. If a PR is still work in progress, awaiting
> review, or has not yet been sufficiently validated, it cannot realistically
> be included in the release.
>
> The community also has limited QA resources. This is especially challenging
> for new features and large improvements, which typically require
> considerably more effort to review and test than bug fixes. As a result,
> some PRs had to be deferred even though they are valuable additions.  The
> deferred PRs have been moved to the 4.24.0 milestone:
> https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.24.0
>
> Hopefully, this provides enough visibility for authors and reviewers to
> continue working on them early in the next development cycle.
>
> I agree that reducing the PR backlog is important, and I think the best way
> to achieve that is to encourage PR authors to get their changes ready for
> review and testing earlier in the release cycle, while also attracting more
> reviewers and testers from the community.
>
> Thanks again for raising the discussion.
>
>
>
> Kind regards,
>
> Wei
>
>
>
>
>
> On Thu, Jul 16, 2026 at 8:42 AM Abhishek Kumar <sh...@apache.org> wrote:
>
> > Hi Wei and other RMs,
> >
> > Thank you for the update and for all the effort that has gone into
> > preparing the release.
> >
> > While it will be great to have a stable 4.23.0 release soon, I was a
> > little disappointed to see a number of self-contained PRs and changes
> > moved out of the 4.23.0 milestone without any accompanying rationale.
> > By "self-contained," I mean changes that are largely isolated and do
> > not affect major existing CloudStack components. Since 4.23.0 is a
> > non-LTS release, I had hoped it would provide an opportunity to
> > include such changes, even if they carry a bit more risk than what
> > we'd typically consider for an LTS release.
> >
> > We currently have a backlog of over 260 open PRs, and I'm concerned
> > that if we continue to take this approach, it will become increasingly
> > difficult to make meaningful progress in reducing that backlog.
> >
> > These are just my personal thoughts, and I fully appreciate the effort
> > that goes into balancing stability with feature delivery. Looking
> > forward to the new release and the many exciting features it will
> > bring.
> >
> > Regards,
> > Abhishek
> >
> > On Tue, 14 Jul 2026 at 22:46, Wei ZHOU <us...@gmail.com> wrote:
> > >
> > > Hi All,
> > >
> > > The code freeze for CloudStack 4.23.0.0 is now in effect. The main branch
> > > will remain frozen until the 4.23.0.0 release. From this point onward,
> > only
> > > blocker, critical, and security fixes will be accepted for merging.
> > >
> > > We will now focus on stabilizing the main branch and preparing the
> > > 4.23.0.0-RC1 release.
> > >
> > > Thanks everyone for your contributions and support in getting us to this
> > > milestone!
> > >
> > >
> > > Kind regards,
> > >
> > > Wei
> > >
> > >
> > >
> > > On Mon, Jul 6, 2026 at 3:19 PM Wei ZHOU <us...@gmail.com> wrote:
> > >
> > > > Hi All,
> > > >
> > > > After discussing this with several community members, we decided to
> > keep
> > > > the 4.23 open for one more week so that the outstanding PRs currently
> > under
> > > > testing or final review can be included in the 4.23.0.0 release.
> > > >
> > > > The updated timeline for 4.23.0 is as follows:
> > > >
> > > >    - *Until July 10, 2026:* Accept new features, bug fixes, and
> > > >    improvements. Features that are not ready to be merged by then will
> > be
> > > >    moved to 4.24.0.
> > > >    - *July 11, 2026:* Freeze the main branch. From this point onward,
> > > >    only critical/blocker fixes will be accepted.
> > > >    - *July 13, 2026, or once all blocker and critical issues have been
> > > >    resolved (whichever is later):* Cut RC1 and begin the voting
> > process.
> > > >
> > > >
> > > > Thanks everyone for the understanding.
> > > >
> > > > Kind regards,
> > > > Wei
> > > >
> > > >
> > > > On Thu, May 21, 2026 at 2:47 PM Fabricio Duarte Junior <
> > > > fabricio@apache.org> wrote:
> > > >
> > > >> (forwarding from users@ to dev@)
> > > >> Hey all,
> > > >>
> > > >> After evaluating the current state and the remaining work for 4.23.0,
> > we
> > > >> have decided to
> > > >> postpone the release by another month. This is to ensure we can
> > deliver a
> > > >> more complete,
> > > >> polished, and well tested version.
> > > >>
> > > >> This postponement was primarily due to the following factors:
> > > >>
> > > >> - A good portion of the features and enhancements planned for 4.23.0
> > [1]
> > > >> are still under
> > > >> development.
> > > >> - We had some delays in addressing security issues from previous
> > cycles.
> > > >> - There is a considerable number of security issues that we intend to
> > > >> solve on this release.
> > > >> - We still have a significant number of open pull requests waiting for
> > > >> review and testing.
> > > >>
> > > >> Hence, the updated timeline for 4.23.0 is the following:
> > > >>
> > > >> - Until July 3rd, 2026: accept new features, bug fixes, and
> > improvements.
> > > >> Features that are not
> > > >> yet ready for merge will be moved to 4.24.0.
> > > >> - July 4th, 2026: freeze the main branch. From this point onward, only
> > > >> critical/blocker fixes will be
> > > >> accepted.
> > > >> - July 6th, 2026, or once all blocker/critical/security issues are
> > > >> resolved (whichever is later): cut
> > > >> RC1 and start the voting process.
> > > >>
> > > >> We kindly ask for the community's support in reviewing and testing the
> > > >> PRs marked for 4.23.0.
> > > >> Additional help in these will be essential to keep the schedule on
> > track.
> > > >>
> > > >> Once again, thanks everyone for the understanding.
> > > >>
> > > >> On 2026/04/07 19:44:17 Wei ZHOU wrote:
> > > >> > Hi all,
> > > >> >
> > > >> > Due to several factors - such as the number of ongoing improvements
> > and
> > > >> new
> > > >> > features, the significant QA effort required, and pending security
> > > >> issues -
> > > >> > we have decided to adjust the timeline. All dates will be postponed
> > by
> > > >> one
> > > >> > month.
> > > >> >
> > > >> > The updated timeline of 4.23.0.0 release is as follows:
> > > >> >
> > > >> >    - *Until June 1st, 2026*: Accept new features, bug fixes, and
> > > >> >    improvements
> > > >> >    - *June 2nd, 2026*: Freeze the main branch. From this point
> > onward,
> > > >> only
> > > >> >    critical/blocker fixes will be accepted
> > > >> >    - *June 3rd, 2026*, or once all blocker/critical/security issues
> > are
> > > >> >    resolved (whichever is later): Cut RC1 and start the voting
> > process
> > > >> (allow
> > > >> >    1-3 weeks for additional RCs if necessary)
> > > >> >
> > > >> >
> > > >> > Thanks for your understanding and collaboration.
> > > >> >
> > > >> >
> > > >> > Kind regards,
> > > >> > Wei & Fabricio
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Tue, Feb 3, 2026 at 9:11 AM Wei ZHOU <us...@gmail.com>
> > wrote:
> > > >> >
> > > >> > > Hi all,
> > > >> > >
> > > >> > > We are planning to work on a CloudStack 4.23.0 release.
> > > >> > >
> > > >> > > CloudStack 4.23.0 will be a Regular release [1], which introduces
> > new
> > > >> > > features
> > > >> > > and enhancements.  It is targeted for users who require the newest
> > > >> > > features as
> > > >> > > early as possible and are able to upgrade when the releases are
> > > >> available.
> > > >> > >
> > > >> > > As discussed [2], I'll serve as the RM for the 4.23.0 release.
> > > >> Fabricio
> > > >> > > Duarte will
> > > >> > > act as the co-RM, assisting with triage, reviews, testing, merges,
> > > >> etc and
> > > >> > > release work.
> > > >> > >
> > > >> > > The timeline for this would be the following (Proposed by
> > Fabricio,
> > > >> > > thanks):
> > > >> > >
> > > >> > > - Until May 3rd 2026: accept new features, bug fixes and
> > improvements.
> > > >> > > - May 4th 2026: freeze the main branch. From this point, we would
> > only
> > > >> > > accept
> > > >> > > critical/blocker fixes.
> > > >> > > - May 11th 2026: cut RC1 and start the vote (1-3 weeks to work on
> > the
> > > >> next
> > > >> > > RCs if necessary).
> > > >> > >
> > > >> > > All open issues and PRs targeted for this release are tracked in
> > the
> > > >> > > 4.23.0
> > > >> > > release milestone [3]. The design document of some features can be
> > > >> found
> > > >> > > at
> > > >> > >
> > > >> > >
> > > >>
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.23+Design+Documents
> > > >> > >
> > > >> > > Please ping us (@weizhouapache or @winterhazel) on your PRs and
> > issues
> > > >> > > that
> > > >> > > are to be included in 4.23.0 on Github. Please let us know if you
> > > >> have any
> > > >> > > questions.
> > > >> > >
> > > >> > >
> > > >> > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> > > >> > > [2]
> > https://lists.apache.org/thread/z7n339vcdym9f494ngb5pkzlxx8mjf2n
> > > >> > > [3] https://github.com/apache/cloudstack/milestone/42
> > > >> > >
> > > >> > >
> > > >> > > Kind regards,
> > > >> > > Wei
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> >

Re: 4.23.0 Release plan

[Wei ZHOU <us...@gmail.com>]

Hi Abhishek,

Thanks for sharing your thoughts. I understand your concern, and I agree
that we should continue looking for ways to reduce the growing PR backlog.

One thing I'd like to clarify is that 4.23 is a regular feature release,
with a primary focus on new features and improvements. Most bug-fix PRs are
instead targeted for the 4.22.2.0 or 4.20.4.0 milestones, which are the
next LTS releases.

Regarding the PRs that were moved out of the 4.23.0 milestone, the main
reason was not necessarily the risk of the changes themselves. Many of them
were simply not ready for review and testing before the code freeze.
According to our merge policy, every PR must be adequately reviewed and
tested before it can be merged. If a PR is still work in progress, awaiting
review, or has not yet been sufficiently validated, it cannot realistically
be included in the release.

The community also has limited QA resources. This is especially challenging
for new features and large improvements, which typically require
considerably more effort to review and test than bug fixes. As a result,
some PRs had to be deferred even though they are valuable additions.  The
deferred PRs have been moved to the 4.24.0 milestone:
https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.24.0

Hopefully, this provides enough visibility for authors and reviewers to
continue working on them early in the next development cycle.

I agree that reducing the PR backlog is important, and I think the best way
to achieve that is to encourage PR authors to get their changes ready for
review and testing earlier in the release cycle, while also attracting more
reviewers and testers from the community.

Thanks again for raising the discussion.



Kind regards,

Wei





On Thu, Jul 16, 2026 at 8:42 AM Abhishek Kumar <sh...@apache.org> wrote:

> Hi Wei and other RMs,
>
> Thank you for the update and for all the effort that has gone into
> preparing the release.
>
> While it will be great to have a stable 4.23.0 release soon, I was a
> little disappointed to see a number of self-contained PRs and changes
> moved out of the 4.23.0 milestone without any accompanying rationale.
> By "self-contained," I mean changes that are largely isolated and do
> not affect major existing CloudStack components. Since 4.23.0 is a
> non-LTS release, I had hoped it would provide an opportunity to
> include such changes, even if they carry a bit more risk than what
> we'd typically consider for an LTS release.
>
> We currently have a backlog of over 260 open PRs, and I'm concerned
> that if we continue to take this approach, it will become increasingly
> difficult to make meaningful progress in reducing that backlog.
>
> These are just my personal thoughts, and I fully appreciate the effort
> that goes into balancing stability with feature delivery. Looking
> forward to the new release and the many exciting features it will
> bring.
>
> Regards,
> Abhishek
>
> On Tue, 14 Jul 2026 at 22:46, Wei ZHOU <us...@gmail.com> wrote:
> >
> > Hi All,
> >
> > The code freeze for CloudStack 4.23.0.0 is now in effect. The main branch
> > will remain frozen until the 4.23.0.0 release. From this point onward,
> only
> > blocker, critical, and security fixes will be accepted for merging.
> >
> > We will now focus on stabilizing the main branch and preparing the
> > 4.23.0.0-RC1 release.
> >
> > Thanks everyone for your contributions and support in getting us to this
> > milestone!
> >
> >
> > Kind regards,
> >
> > Wei
> >
> >
> >
> > On Mon, Jul 6, 2026 at 3:19 PM Wei ZHOU <us...@gmail.com> wrote:
> >
> > > Hi All,
> > >
> > > After discussing this with several community members, we decided to
> keep
> > > the 4.23 open for one more week so that the outstanding PRs currently
> under
> > > testing or final review can be included in the 4.23.0.0 release.
> > >
> > > The updated timeline for 4.23.0 is as follows:
> > >
> > >    - *Until July 10, 2026:* Accept new features, bug fixes, and
> > >    improvements. Features that are not ready to be merged by then will
> be
> > >    moved to 4.24.0.
> > >    - *July 11, 2026:* Freeze the main branch. From this point onward,
> > >    only critical/blocker fixes will be accepted.
> > >    - *July 13, 2026, or once all blocker and critical issues have been
> > >    resolved (whichever is later):* Cut RC1 and begin the voting
> process.
> > >
> > >
> > > Thanks everyone for the understanding.
> > >
> > > Kind regards,
> > > Wei
> > >
> > >
> > > On Thu, May 21, 2026 at 2:47 PM Fabricio Duarte Junior <
> > > fabricio@apache.org> wrote:
> > >
> > >> (forwarding from users@ to dev@)
> > >> Hey all,
> > >>
> > >> After evaluating the current state and the remaining work for 4.23.0,
> we
> > >> have decided to
> > >> postpone the release by another month. This is to ensure we can
> deliver a
> > >> more complete,
> > >> polished, and well tested version.
> > >>
> > >> This postponement was primarily due to the following factors:
> > >>
> > >> - A good portion of the features and enhancements planned for 4.23.0
> [1]
> > >> are still under
> > >> development.
> > >> - We had some delays in addressing security issues from previous
> cycles.
> > >> - There is a considerable number of security issues that we intend to
> > >> solve on this release.
> > >> - We still have a significant number of open pull requests waiting for
> > >> review and testing.
> > >>
> > >> Hence, the updated timeline for 4.23.0 is the following:
> > >>
> > >> - Until July 3rd, 2026: accept new features, bug fixes, and
> improvements.
> > >> Features that are not
> > >> yet ready for merge will be moved to 4.24.0.
> > >> - July 4th, 2026: freeze the main branch. From this point onward, only
> > >> critical/blocker fixes will be
> > >> accepted.
> > >> - July 6th, 2026, or once all blocker/critical/security issues are
> > >> resolved (whichever is later): cut
> > >> RC1 and start the voting process.
> > >>
> > >> We kindly ask for the community's support in reviewing and testing the
> > >> PRs marked for 4.23.0.
> > >> Additional help in these will be essential to keep the schedule on
> track.
> > >>
> > >> Once again, thanks everyone for the understanding.
> > >>
> > >> On 2026/04/07 19:44:17 Wei ZHOU wrote:
> > >> > Hi all,
> > >> >
> > >> > Due to several factors - such as the number of ongoing improvements
> and
> > >> new
> > >> > features, the significant QA effort required, and pending security
> > >> issues -
> > >> > we have decided to adjust the timeline. All dates will be postponed
> by
> > >> one
> > >> > month.
> > >> >
> > >> > The updated timeline of 4.23.0.0 release is as follows:
> > >> >
> > >> >    - *Until June 1st, 2026*: Accept new features, bug fixes, and
> > >> >    improvements
> > >> >    - *June 2nd, 2026*: Freeze the main branch. From this point
> onward,
> > >> only
> > >> >    critical/blocker fixes will be accepted
> > >> >    - *June 3rd, 2026*, or once all blocker/critical/security issues
> are
> > >> >    resolved (whichever is later): Cut RC1 and start the voting
> process
> > >> (allow
> > >> >    1-3 weeks for additional RCs if necessary)
> > >> >
> > >> >
> > >> > Thanks for your understanding and collaboration.
> > >> >
> > >> >
> > >> > Kind regards,
> > >> > Wei & Fabricio
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Tue, Feb 3, 2026 at 9:11 AM Wei ZHOU <us...@gmail.com>
> wrote:
> > >> >
> > >> > > Hi all,
> > >> > >
> > >> > > We are planning to work on a CloudStack 4.23.0 release.
> > >> > >
> > >> > > CloudStack 4.23.0 will be a Regular release [1], which introduces
> new
> > >> > > features
> > >> > > and enhancements.  It is targeted for users who require the newest
> > >> > > features as
> > >> > > early as possible and are able to upgrade when the releases are
> > >> available.
> > >> > >
> > >> > > As discussed [2], I'll serve as the RM for the 4.23.0 release.
> > >> Fabricio
> > >> > > Duarte will
> > >> > > act as the co-RM, assisting with triage, reviews, testing, merges,
> > >> etc and
> > >> > > release work.
> > >> > >
> > >> > > The timeline for this would be the following (Proposed by
> Fabricio,
> > >> > > thanks):
> > >> > >
> > >> > > - Until May 3rd 2026: accept new features, bug fixes and
> improvements.
> > >> > > - May 4th 2026: freeze the main branch. From this point, we would
> only
> > >> > > accept
> > >> > > critical/blocker fixes.
> > >> > > - May 11th 2026: cut RC1 and start the vote (1-3 weeks to work on
> the
> > >> next
> > >> > > RCs if necessary).
> > >> > >
> > >> > > All open issues and PRs targeted for this release are tracked in
> the
> > >> > > 4.23.0
> > >> > > release milestone [3]. The design document of some features can be
> > >> found
> > >> > > at
> > >> > >
> > >> > >
> > >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.23+Design+Documents
> > >> > >
> > >> > > Please ping us (@weizhouapache or @winterhazel) on your PRs and
> issues
> > >> > > that
> > >> > > are to be included in 4.23.0 on Github. Please let us know if you
> > >> have any
> > >> > > questions.
> > >> > >
> > >> > >
> > >> > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> > >> > > [2]
> https://lists.apache.org/thread/z7n339vcdym9f494ngb5pkzlxx8mjf2n
> > >> > > [3] https://github.com/apache/cloudstack/milestone/42
> > >> > >
> > >> > >
> > >> > > Kind regards,
> > >> > > Wei
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
>

Re: 4.23.0 Release plan

[Wei ZHOU <us...@gmail.com>]

Hi Abhishek,

Thanks for sharing your thoughts. I understand your concern, and I agree
that we should continue looking for ways to reduce the growing PR backlog.

One thing I'd like to clarify is that 4.23 is a regular feature release,
with a primary focus on new features and improvements. Most bug-fix PRs are
instead targeted for the 4.22.2.0 or 4.20.4.0 milestones, which are the
next LTS releases.

Regarding the PRs that were moved out of the 4.23.0 milestone, the main
reason was not necessarily the risk of the changes themselves. Many of them
were simply not ready for review and testing before the code freeze.
According to our merge policy, every PR must be adequately reviewed and
tested before it can be merged. If a PR is still work in progress, awaiting
review, or has not yet been sufficiently validated, it cannot realistically
be included in the release.

The community also has limited QA resources. This is especially challenging
for new features and large improvements, which typically require
considerably more effort to review and test than bug fixes. As a result,
some PRs had to be deferred even though they are valuable additions.  The
deferred PRs have been moved to the 4.24.0 milestone:
https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.24.0

Hopefully, this provides enough visibility for authors and reviewers to
continue working on them early in the next development cycle.

I agree that reducing the PR backlog is important, and I think the best way
to achieve that is to encourage PR authors to get their changes ready for
review and testing earlier in the release cycle, while also attracting more
reviewers and testers from the community.

Thanks again for raising the discussion.



Kind regards,

Wei





On Thu, Jul 16, 2026 at 8:42 AM Abhishek Kumar <sh...@apache.org> wrote:

> Hi Wei and other RMs,
>
> Thank you for the update and for all the effort that has gone into
> preparing the release.
>
> While it will be great to have a stable 4.23.0 release soon, I was a
> little disappointed to see a number of self-contained PRs and changes
> moved out of the 4.23.0 milestone without any accompanying rationale.
> By "self-contained," I mean changes that are largely isolated and do
> not affect major existing CloudStack components. Since 4.23.0 is a
> non-LTS release, I had hoped it would provide an opportunity to
> include such changes, even if they carry a bit more risk than what
> we'd typically consider for an LTS release.
>
> We currently have a backlog of over 260 open PRs, and I'm concerned
> that if we continue to take this approach, it will become increasingly
> difficult to make meaningful progress in reducing that backlog.
>
> These are just my personal thoughts, and I fully appreciate the effort
> that goes into balancing stability with feature delivery. Looking
> forward to the new release and the many exciting features it will
> bring.
>
> Regards,
> Abhishek
>
> On Tue, 14 Jul 2026 at 22:46, Wei ZHOU <us...@gmail.com> wrote:
> >
> > Hi All,
> >
> > The code freeze for CloudStack 4.23.0.0 is now in effect. The main branch
> > will remain frozen until the 4.23.0.0 release. From this point onward,
> only
> > blocker, critical, and security fixes will be accepted for merging.
> >
> > We will now focus on stabilizing the main branch and preparing the
> > 4.23.0.0-RC1 release.
> >
> > Thanks everyone for your contributions and support in getting us to this
> > milestone!
> >
> >
> > Kind regards,
> >
> > Wei
> >
> >
> >
> > On Mon, Jul 6, 2026 at 3:19 PM Wei ZHOU <us...@gmail.com> wrote:
> >
> > > Hi All,
> > >
> > > After discussing this with several community members, we decided to
> keep
> > > the 4.23 open for one more week so that the outstanding PRs currently
> under
> > > testing or final review can be included in the 4.23.0.0 release.
> > >
> > > The updated timeline for 4.23.0 is as follows:
> > >
> > >    - *Until July 10, 2026:* Accept new features, bug fixes, and
> > >    improvements. Features that are not ready to be merged by then will
> be
> > >    moved to 4.24.0.
> > >    - *July 11, 2026:* Freeze the main branch. From this point onward,
> > >    only critical/blocker fixes will be accepted.
> > >    - *July 13, 2026, or once all blocker and critical issues have been
> > >    resolved (whichever is later):* Cut RC1 and begin the voting
> process.
> > >
> > >
> > > Thanks everyone for the understanding.
> > >
> > > Kind regards,
> > > Wei
> > >
> > >
> > > On Thu, May 21, 2026 at 2:47 PM Fabricio Duarte Junior <
> > > fabricio@apache.org> wrote:
> > >
> > >> (forwarding from users@ to dev@)
> > >> Hey all,
> > >>
> > >> After evaluating the current state and the remaining work for 4.23.0,
> we
> > >> have decided to
> > >> postpone the release by another month. This is to ensure we can
> deliver a
> > >> more complete,
> > >> polished, and well tested version.
> > >>
> > >> This postponement was primarily due to the following factors:
> > >>
> > >> - A good portion of the features and enhancements planned for 4.23.0
> [1]
> > >> are still under
> > >> development.
> > >> - We had some delays in addressing security issues from previous
> cycles.
> > >> - There is a considerable number of security issues that we intend to
> > >> solve on this release.
> > >> - We still have a significant number of open pull requests waiting for
> > >> review and testing.
> > >>
> > >> Hence, the updated timeline for 4.23.0 is the following:
> > >>
> > >> - Until July 3rd, 2026: accept new features, bug fixes, and
> improvements.
> > >> Features that are not
> > >> yet ready for merge will be moved to 4.24.0.
> > >> - July 4th, 2026: freeze the main branch. From this point onward, only
> > >> critical/blocker fixes will be
> > >> accepted.
> > >> - July 6th, 2026, or once all blocker/critical/security issues are
> > >> resolved (whichever is later): cut
> > >> RC1 and start the voting process.
> > >>
> > >> We kindly ask for the community's support in reviewing and testing the
> > >> PRs marked for 4.23.0.
> > >> Additional help in these will be essential to keep the schedule on
> track.
> > >>
> > >> Once again, thanks everyone for the understanding.
> > >>
> > >> On 2026/04/07 19:44:17 Wei ZHOU wrote:
> > >> > Hi all,
> > >> >
> > >> > Due to several factors - such as the number of ongoing improvements
> and
> > >> new
> > >> > features, the significant QA effort required, and pending security
> > >> issues -
> > >> > we have decided to adjust the timeline. All dates will be postponed
> by
> > >> one
> > >> > month.
> > >> >
> > >> > The updated timeline of 4.23.0.0 release is as follows:
> > >> >
> > >> >    - *Until June 1st, 2026*: Accept new features, bug fixes, and
> > >> >    improvements
> > >> >    - *June 2nd, 2026*: Freeze the main branch. From this point
> onward,
> > >> only
> > >> >    critical/blocker fixes will be accepted
> > >> >    - *June 3rd, 2026*, or once all blocker/critical/security issues
> are
> > >> >    resolved (whichever is later): Cut RC1 and start the voting
> process
> > >> (allow
> > >> >    1-3 weeks for additional RCs if necessary)
> > >> >
> > >> >
> > >> > Thanks for your understanding and collaboration.
> > >> >
> > >> >
> > >> > Kind regards,
> > >> > Wei & Fabricio
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Tue, Feb 3, 2026 at 9:11 AM Wei ZHOU <us...@gmail.com>
> wrote:
> > >> >
> > >> > > Hi all,
> > >> > >
> > >> > > We are planning to work on a CloudStack 4.23.0 release.
> > >> > >
> > >> > > CloudStack 4.23.0 will be a Regular release [1], which introduces
> new
> > >> > > features
> > >> > > and enhancements.  It is targeted for users who require the newest
> > >> > > features as
> > >> > > early as possible and are able to upgrade when the releases are
> > >> available.
> > >> > >
> > >> > > As discussed [2], I'll serve as the RM for the 4.23.0 release.
> > >> Fabricio
> > >> > > Duarte will
> > >> > > act as the co-RM, assisting with triage, reviews, testing, merges,
> > >> etc and
> > >> > > release work.
> > >> > >
> > >> > > The timeline for this would be the following (Proposed by
> Fabricio,
> > >> > > thanks):
> > >> > >
> > >> > > - Until May 3rd 2026: accept new features, bug fixes and
> improvements.
> > >> > > - May 4th 2026: freeze the main branch. From this point, we would
> only
> > >> > > accept
> > >> > > critical/blocker fixes.
> > >> > > - May 11th 2026: cut RC1 and start the vote (1-3 weeks to work on
> the
> > >> next
> > >> > > RCs if necessary).
> > >> > >
> > >> > > All open issues and PRs targeted for this release are tracked in
> the
> > >> > > 4.23.0
> > >> > > release milestone [3]. The design document of some features can be
> > >> found
> > >> > > at
> > >> > >
> > >> > >
> > >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.23+Design+Documents
> > >> > >
> > >> > > Please ping us (@weizhouapache or @winterhazel) on your PRs and
> issues
> > >> > > that
> > >> > > are to be included in 4.23.0 on Github. Please let us know if you
> > >> have any
> > >> > > questions.
> > >> > >
> > >> > >
> > >> > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> > >> > > [2]
> https://lists.apache.org/thread/z7n339vcdym9f494ngb5pkzlxx8mjf2n
> > >> > > [3] https://github.com/apache/cloudstack/milestone/42
> > >> > >
> > >> > >
> > >> > > Kind regards,
> > >> > > Wei
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
>

Re: 4.23.0 Release plan

[Abhishek Kumar <sh...@apache.org>]

Hi Wei and other RMs,

Thank you for the update and for all the effort that has gone into
preparing the release.

While it will be great to have a stable 4.23.0 release soon, I was a
little disappointed to see a number of self-contained PRs and changes
moved out of the 4.23.0 milestone without any accompanying rationale.
By "self-contained," I mean changes that are largely isolated and do
not affect major existing CloudStack components. Since 4.23.0 is a
non-LTS release, I had hoped it would provide an opportunity to
include such changes, even if they carry a bit more risk than what
we'd typically consider for an LTS release.

We currently have a backlog of over 260 open PRs, and I'm concerned
that if we continue to take this approach, it will become increasingly
difficult to make meaningful progress in reducing that backlog.

These are just my personal thoughts, and I fully appreciate the effort
that goes into balancing stability with feature delivery. Looking
forward to the new release and the many exciting features it will
bring.

Regards,
Abhishek

On Tue, 14 Jul 2026 at 22:46, Wei ZHOU <us...@gmail.com> wrote:
>
> Hi All,
>
> The code freeze for CloudStack 4.23.0.0 is now in effect. The main branch
> will remain frozen until the 4.23.0.0 release. From this point onward, only
> blocker, critical, and security fixes will be accepted for merging.
>
> We will now focus on stabilizing the main branch and preparing the
> 4.23.0.0-RC1 release.
>
> Thanks everyone for your contributions and support in getting us to this
> milestone!
>
>
> Kind regards,
>
> Wei
>
>
>
> On Mon, Jul 6, 2026 at 3:19 PM Wei ZHOU <us...@gmail.com> wrote:
>
> > Hi All,
> >
> > After discussing this with several community members, we decided to keep
> > the 4.23 open for one more week so that the outstanding PRs currently under
> > testing or final review can be included in the 4.23.0.0 release.
> >
> > The updated timeline for 4.23.0 is as follows:
> >
> >    - *Until July 10, 2026:* Accept new features, bug fixes, and
> >    improvements. Features that are not ready to be merged by then will be
> >    moved to 4.24.0.
> >    - *July 11, 2026:* Freeze the main branch. From this point onward,
> >    only critical/blocker fixes will be accepted.
> >    - *July 13, 2026, or once all blocker and critical issues have been
> >    resolved (whichever is later):* Cut RC1 and begin the voting process.
> >
> >
> > Thanks everyone for the understanding.
> >
> > Kind regards,
> > Wei
> >
> >
> > On Thu, May 21, 2026 at 2:47 PM Fabricio Duarte Junior <
> > fabricio@apache.org> wrote:
> >
> >> (forwarding from users@ to dev@)
> >> Hey all,
> >>
> >> After evaluating the current state and the remaining work for 4.23.0, we
> >> have decided to
> >> postpone the release by another month. This is to ensure we can deliver a
> >> more complete,
> >> polished, and well tested version.
> >>
> >> This postponement was primarily due to the following factors:
> >>
> >> - A good portion of the features and enhancements planned for 4.23.0 [1]
> >> are still under
> >> development.
> >> - We had some delays in addressing security issues from previous cycles.
> >> - There is a considerable number of security issues that we intend to
> >> solve on this release.
> >> - We still have a significant number of open pull requests waiting for
> >> review and testing.
> >>
> >> Hence, the updated timeline for 4.23.0 is the following:
> >>
> >> - Until July 3rd, 2026: accept new features, bug fixes, and improvements.
> >> Features that are not
> >> yet ready for merge will be moved to 4.24.0.
> >> - July 4th, 2026: freeze the main branch. From this point onward, only
> >> critical/blocker fixes will be
> >> accepted.
> >> - July 6th, 2026, or once all blocker/critical/security issues are
> >> resolved (whichever is later): cut
> >> RC1 and start the voting process.
> >>
> >> We kindly ask for the community's support in reviewing and testing the
> >> PRs marked for 4.23.0.
> >> Additional help in these will be essential to keep the schedule on track.
> >>
> >> Once again, thanks everyone for the understanding.
> >>
> >> On 2026/04/07 19:44:17 Wei ZHOU wrote:
> >> > Hi all,
> >> >
> >> > Due to several factors - such as the number of ongoing improvements and
> >> new
> >> > features, the significant QA effort required, and pending security
> >> issues -
> >> > we have decided to adjust the timeline. All dates will be postponed by
> >> one
> >> > month.
> >> >
> >> > The updated timeline of 4.23.0.0 release is as follows:
> >> >
> >> >    - *Until June 1st, 2026*: Accept new features, bug fixes, and
> >> >    improvements
> >> >    - *June 2nd, 2026*: Freeze the main branch. From this point onward,
> >> only
> >> >    critical/blocker fixes will be accepted
> >> >    - *June 3rd, 2026*, or once all blocker/critical/security issues are
> >> >    resolved (whichever is later): Cut RC1 and start the voting process
> >> (allow
> >> >    1-3 weeks for additional RCs if necessary)
> >> >
> >> >
> >> > Thanks for your understanding and collaboration.
> >> >
> >> >
> >> > Kind regards,
> >> > Wei & Fabricio
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Feb 3, 2026 at 9:11 AM Wei ZHOU <us...@gmail.com> wrote:
> >> >
> >> > > Hi all,
> >> > >
> >> > > We are planning to work on a CloudStack 4.23.0 release.
> >> > >
> >> > > CloudStack 4.23.0 will be a Regular release [1], which introduces new
> >> > > features
> >> > > and enhancements.  It is targeted for users who require the newest
> >> > > features as
> >> > > early as possible and are able to upgrade when the releases are
> >> available.
> >> > >
> >> > > As discussed [2], I'll serve as the RM for the 4.23.0 release.
> >> Fabricio
> >> > > Duarte will
> >> > > act as the co-RM, assisting with triage, reviews, testing, merges,
> >> etc and
> >> > > release work.
> >> > >
> >> > > The timeline for this would be the following (Proposed by Fabricio,
> >> > > thanks):
> >> > >
> >> > > - Until May 3rd 2026: accept new features, bug fixes and improvements.
> >> > > - May 4th 2026: freeze the main branch. From this point, we would only
> >> > > accept
> >> > > critical/blocker fixes.
> >> > > - May 11th 2026: cut RC1 and start the vote (1-3 weeks to work on the
> >> next
> >> > > RCs if necessary).
> >> > >
> >> > > All open issues and PRs targeted for this release are tracked in the
> >> > > 4.23.0
> >> > > release milestone [3]. The design document of some features can be
> >> found
> >> > > at
> >> > >
> >> > >
> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.23+Design+Documents
> >> > >
> >> > > Please ping us (@weizhouapache or @winterhazel) on your PRs and issues
> >> > > that
> >> > > are to be included in 4.23.0 on Github. Please let us know if you
> >> have any
> >> > > questions.
> >> > >
> >> > >
> >> > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> >> > > [2] https://lists.apache.org/thread/z7n339vcdym9f494ngb5pkzlxx8mjf2n
> >> > > [3] https://github.com/apache/cloudstack/milestone/42
> >> > >
> >> > >
> >> > > Kind regards,
> >> > > Wei
> >> > >
> >> > >
> >> >
> >>
> >

Re: 4.23.0 Release plan

[Abhishek Kumar <sh...@apache.org>]

Hi Wei and other RMs,

Thank you for the update and for all the effort that has gone into
preparing the release.

While it will be great to have a stable 4.23.0 release soon, I was a
little disappointed to see a number of self-contained PRs and changes
moved out of the 4.23.0 milestone without any accompanying rationale.
By "self-contained," I mean changes that are largely isolated and do
not affect major existing CloudStack components. Since 4.23.0 is a
non-LTS release, I had hoped it would provide an opportunity to
include such changes, even if they carry a bit more risk than what
we'd typically consider for an LTS release.

We currently have a backlog of over 260 open PRs, and I'm concerned
that if we continue to take this approach, it will become increasingly
difficult to make meaningful progress in reducing that backlog.

These are just my personal thoughts, and I fully appreciate the effort
that goes into balancing stability with feature delivery. Looking
forward to the new release and the many exciting features it will
bring.

Regards,
Abhishek

On Tue, 14 Jul 2026 at 22:46, Wei ZHOU <us...@gmail.com> wrote:
>
> Hi All,
>
> The code freeze for CloudStack 4.23.0.0 is now in effect. The main branch
> will remain frozen until the 4.23.0.0 release. From this point onward, only
> blocker, critical, and security fixes will be accepted for merging.
>
> We will now focus on stabilizing the main branch and preparing the
> 4.23.0.0-RC1 release.
>
> Thanks everyone for your contributions and support in getting us to this
> milestone!
>
>
> Kind regards,
>
> Wei
>
>
>
> On Mon, Jul 6, 2026 at 3:19 PM Wei ZHOU <us...@gmail.com> wrote:
>
> > Hi All,
> >
> > After discussing this with several community members, we decided to keep
> > the 4.23 open for one more week so that the outstanding PRs currently under
> > testing or final review can be included in the 4.23.0.0 release.
> >
> > The updated timeline for 4.23.0 is as follows:
> >
> >    - *Until July 10, 2026:* Accept new features, bug fixes, and
> >    improvements. Features that are not ready to be merged by then will be
> >    moved to 4.24.0.
> >    - *July 11, 2026:* Freeze the main branch. From this point onward,
> >    only critical/blocker fixes will be accepted.
> >    - *July 13, 2026, or once all blocker and critical issues have been
> >    resolved (whichever is later):* Cut RC1 and begin the voting process.
> >
> >
> > Thanks everyone for the understanding.
> >
> > Kind regards,
> > Wei
> >
> >
> > On Thu, May 21, 2026 at 2:47 PM Fabricio Duarte Junior <
> > fabricio@apache.org> wrote:
> >
> >> (forwarding from users@ to dev@)
> >> Hey all,
> >>
> >> After evaluating the current state and the remaining work for 4.23.0, we
> >> have decided to
> >> postpone the release by another month. This is to ensure we can deliver a
> >> more complete,
> >> polished, and well tested version.
> >>
> >> This postponement was primarily due to the following factors:
> >>
> >> - A good portion of the features and enhancements planned for 4.23.0 [1]
> >> are still under
> >> development.
> >> - We had some delays in addressing security issues from previous cycles.
> >> - There is a considerable number of security issues that we intend to
> >> solve on this release.
> >> - We still have a significant number of open pull requests waiting for
> >> review and testing.
> >>
> >> Hence, the updated timeline for 4.23.0 is the following:
> >>
> >> - Until July 3rd, 2026: accept new features, bug fixes, and improvements.
> >> Features that are not
> >> yet ready for merge will be moved to 4.24.0.
> >> - July 4th, 2026: freeze the main branch. From this point onward, only
> >> critical/blocker fixes will be
> >> accepted.
> >> - July 6th, 2026, or once all blocker/critical/security issues are
> >> resolved (whichever is later): cut
> >> RC1 and start the voting process.
> >>
> >> We kindly ask for the community's support in reviewing and testing the
> >> PRs marked for 4.23.0.
> >> Additional help in these will be essential to keep the schedule on track.
> >>
> >> Once again, thanks everyone for the understanding.
> >>
> >> On 2026/04/07 19:44:17 Wei ZHOU wrote:
> >> > Hi all,
> >> >
> >> > Due to several factors - such as the number of ongoing improvements and
> >> new
> >> > features, the significant QA effort required, and pending security
> >> issues -
> >> > we have decided to adjust the timeline. All dates will be postponed by
> >> one
> >> > month.
> >> >
> >> > The updated timeline of 4.23.0.0 release is as follows:
> >> >
> >> >    - *Until June 1st, 2026*: Accept new features, bug fixes, and
> >> >    improvements
> >> >    - *June 2nd, 2026*: Freeze the main branch. From this point onward,
> >> only
> >> >    critical/blocker fixes will be accepted
> >> >    - *June 3rd, 2026*, or once all blocker/critical/security issues are
> >> >    resolved (whichever is later): Cut RC1 and start the voting process
> >> (allow
> >> >    1-3 weeks for additional RCs if necessary)
> >> >
> >> >
> >> > Thanks for your understanding and collaboration.
> >> >
> >> >
> >> > Kind regards,
> >> > Wei & Fabricio
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Feb 3, 2026 at 9:11 AM Wei ZHOU <us...@gmail.com> wrote:
> >> >
> >> > > Hi all,
> >> > >
> >> > > We are planning to work on a CloudStack 4.23.0 release.
> >> > >
> >> > > CloudStack 4.23.0 will be a Regular release [1], which introduces new
> >> > > features
> >> > > and enhancements.  It is targeted for users who require the newest
> >> > > features as
> >> > > early as possible and are able to upgrade when the releases are
> >> available.
> >> > >
> >> > > As discussed [2], I'll serve as the RM for the 4.23.0 release.
> >> Fabricio
> >> > > Duarte will
> >> > > act as the co-RM, assisting with triage, reviews, testing, merges,
> >> etc and
> >> > > release work.
> >> > >
> >> > > The timeline for this would be the following (Proposed by Fabricio,
> >> > > thanks):
> >> > >
> >> > > - Until May 3rd 2026: accept new features, bug fixes and improvements.
> >> > > - May 4th 2026: freeze the main branch. From this point, we would only
> >> > > accept
> >> > > critical/blocker fixes.
> >> > > - May 11th 2026: cut RC1 and start the vote (1-3 weeks to work on the
> >> next
> >> > > RCs if necessary).
> >> > >
> >> > > All open issues and PRs targeted for this release are tracked in the
> >> > > 4.23.0
> >> > > release milestone [3]. The design document of some features can be
> >> found
> >> > > at
> >> > >
> >> > >
> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.23+Design+Documents
> >> > >
> >> > > Please ping us (@weizhouapache or @winterhazel) on your PRs and issues
> >> > > that
> >> > > are to be included in 4.23.0 on Github. Please let us know if you
> >> have any
> >> > > questions.
> >> > >
> >> > >
> >> > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> >> > > [2] https://lists.apache.org/thread/z7n339vcdym9f494ngb5pkzlxx8mjf2n
> >> > > [3] https://github.com/apache/cloudstack/milestone/42
> >> > >
> >> > >
> >> > > Kind regards,
> >> > > Wei
> >> > >
> >> > >
> >> >
> >>
> >

Re: 4.23.0 Release plan

[Wei ZHOU <us...@gmail.com>]

Hi All,

The code freeze for CloudStack 4.23.0.0 is now in effect. The main branch
will remain frozen until the 4.23.0.0 release. From this point onward, only
blocker, critical, and security fixes will be accepted for merging.

We will now focus on stabilizing the main branch and preparing the
4.23.0.0-RC1 release.

Thanks everyone for your contributions and support in getting us to this
milestone!


Kind regards,

Wei



On Mon, Jul 6, 2026 at 3:19 PM Wei ZHOU <us...@gmail.com> wrote:

> Hi All,
>
> After discussing this with several community members, we decided to keep
> the 4.23 open for one more week so that the outstanding PRs currently under
> testing or final review can be included in the 4.23.0.0 release.
>
> The updated timeline for 4.23.0 is as follows:
>
>    - *Until July 10, 2026:* Accept new features, bug fixes, and
>    improvements. Features that are not ready to be merged by then will be
>    moved to 4.24.0.
>    - *July 11, 2026:* Freeze the main branch. From this point onward,
>    only critical/blocker fixes will be accepted.
>    - *July 13, 2026, or once all blocker and critical issues have been
>    resolved (whichever is later):* Cut RC1 and begin the voting process.
>
>
> Thanks everyone for the understanding.
>
> Kind regards,
> Wei
>
>
> On Thu, May 21, 2026 at 2:47 PM Fabricio Duarte Junior <
> fabricio@apache.org> wrote:
>
>> (forwarding from users@ to dev@)
>> Hey all,
>>
>> After evaluating the current state and the remaining work for 4.23.0, we
>> have decided to
>> postpone the release by another month. This is to ensure we can deliver a
>> more complete,
>> polished, and well tested version.
>>
>> This postponement was primarily due to the following factors:
>>
>> - A good portion of the features and enhancements planned for 4.23.0 [1]
>> are still under
>> development.
>> - We had some delays in addressing security issues from previous cycles.
>> - There is a considerable number of security issues that we intend to
>> solve on this release.
>> - We still have a significant number of open pull requests waiting for
>> review and testing.
>>
>> Hence, the updated timeline for 4.23.0 is the following:
>>
>> - Until July 3rd, 2026: accept new features, bug fixes, and improvements.
>> Features that are not
>> yet ready for merge will be moved to 4.24.0.
>> - July 4th, 2026: freeze the main branch. From this point onward, only
>> critical/blocker fixes will be
>> accepted.
>> - July 6th, 2026, or once all blocker/critical/security issues are
>> resolved (whichever is later): cut
>> RC1 and start the voting process.
>>
>> We kindly ask for the community's support in reviewing and testing the
>> PRs marked for 4.23.0.
>> Additional help in these will be essential to keep the schedule on track.
>>
>> Once again, thanks everyone for the understanding.
>>
>> On 2026/04/07 19:44:17 Wei ZHOU wrote:
>> > Hi all,
>> >
>> > Due to several factors - such as the number of ongoing improvements and
>> new
>> > features, the significant QA effort required, and pending security
>> issues -
>> > we have decided to adjust the timeline. All dates will be postponed by
>> one
>> > month.
>> >
>> > The updated timeline of 4.23.0.0 release is as follows:
>> >
>> >    - *Until June 1st, 2026*: Accept new features, bug fixes, and
>> >    improvements
>> >    - *June 2nd, 2026*: Freeze the main branch. From this point onward,
>> only
>> >    critical/blocker fixes will be accepted
>> >    - *June 3rd, 2026*, or once all blocker/critical/security issues are
>> >    resolved (whichever is later): Cut RC1 and start the voting process
>> (allow
>> >    1-3 weeks for additional RCs if necessary)
>> >
>> >
>> > Thanks for your understanding and collaboration.
>> >
>> >
>> > Kind regards,
>> > Wei & Fabricio
>> >
>> >
>> >
>> >
>> > On Tue, Feb 3, 2026 at 9:11 AM Wei ZHOU <us...@gmail.com> wrote:
>> >
>> > > Hi all,
>> > >
>> > > We are planning to work on a CloudStack 4.23.0 release.
>> > >
>> > > CloudStack 4.23.0 will be a Regular release [1], which introduces new
>> > > features
>> > > and enhancements.  It is targeted for users who require the newest
>> > > features as
>> > > early as possible and are able to upgrade when the releases are
>> available.
>> > >
>> > > As discussed [2], I'll serve as the RM for the 4.23.0 release.
>> Fabricio
>> > > Duarte will
>> > > act as the co-RM, assisting with triage, reviews, testing, merges,
>> etc and
>> > > release work.
>> > >
>> > > The timeline for this would be the following (Proposed by Fabricio,
>> > > thanks):
>> > >
>> > > - Until May 3rd 2026: accept new features, bug fixes and improvements.
>> > > - May 4th 2026: freeze the main branch. From this point, we would only
>> > > accept
>> > > critical/blocker fixes.
>> > > - May 11th 2026: cut RC1 and start the vote (1-3 weeks to work on the
>> next
>> > > RCs if necessary).
>> > >
>> > > All open issues and PRs targeted for this release are tracked in the
>> > > 4.23.0
>> > > release milestone [3]. The design document of some features can be
>> found
>> > > at
>> > >
>> > >
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.23+Design+Documents
>> > >
>> > > Please ping us (@weizhouapache or @winterhazel) on your PRs and issues
>> > > that
>> > > are to be included in 4.23.0 on Github. Please let us know if you
>> have any
>> > > questions.
>> > >
>> > >
>> > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>> > > [2] https://lists.apache.org/thread/z7n339vcdym9f494ngb5pkzlxx8mjf2n
>> > > [3] https://github.com/apache/cloudstack/milestone/42
>> > >
>> > >
>> > > Kind regards,
>> > > Wei
>> > >
>> > >
>> >
>>
>

Re: 4.23.0 Release plan

[Wei ZHOU <us...@gmail.com>]

Hi All,

The code freeze for CloudStack 4.23.0.0 is now in effect. The main branch
will remain frozen until the 4.23.0.0 release. From this point onward, only
blocker, critical, and security fixes will be accepted for merging.

We will now focus on stabilizing the main branch and preparing the
4.23.0.0-RC1 release.

Thanks everyone for your contributions and support in getting us to this
milestone!


Kind regards,

Wei



On Mon, Jul 6, 2026 at 3:19 PM Wei ZHOU <us...@gmail.com> wrote:

> Hi All,
>
> After discussing this with several community members, we decided to keep
> the 4.23 open for one more week so that the outstanding PRs currently under
> testing or final review can be included in the 4.23.0.0 release.
>
> The updated timeline for 4.23.0 is as follows:
>
>    - *Until July 10, 2026:* Accept new features, bug fixes, and
>    improvements. Features that are not ready to be merged by then will be
>    moved to 4.24.0.
>    - *July 11, 2026:* Freeze the main branch. From this point onward,
>    only critical/blocker fixes will be accepted.
>    - *July 13, 2026, or once all blocker and critical issues have been
>    resolved (whichever is later):* Cut RC1 and begin the voting process.
>
>
> Thanks everyone for the understanding.
>
> Kind regards,
> Wei
>
>
> On Thu, May 21, 2026 at 2:47 PM Fabricio Duarte Junior <
> fabricio@apache.org> wrote:
>
>> (forwarding from users@ to dev@)
>> Hey all,
>>
>> After evaluating the current state and the remaining work for 4.23.0, we
>> have decided to
>> postpone the release by another month. This is to ensure we can deliver a
>> more complete,
>> polished, and well tested version.
>>
>> This postponement was primarily due to the following factors:
>>
>> - A good portion of the features and enhancements planned for 4.23.0 [1]
>> are still under
>> development.
>> - We had some delays in addressing security issues from previous cycles.
>> - There is a considerable number of security issues that we intend to
>> solve on this release.
>> - We still have a significant number of open pull requests waiting for
>> review and testing.
>>
>> Hence, the updated timeline for 4.23.0 is the following:
>>
>> - Until July 3rd, 2026: accept new features, bug fixes, and improvements.
>> Features that are not
>> yet ready for merge will be moved to 4.24.0.
>> - July 4th, 2026: freeze the main branch. From this point onward, only
>> critical/blocker fixes will be
>> accepted.
>> - July 6th, 2026, or once all blocker/critical/security issues are
>> resolved (whichever is later): cut
>> RC1 and start the voting process.
>>
>> We kindly ask for the community's support in reviewing and testing the
>> PRs marked for 4.23.0.
>> Additional help in these will be essential to keep the schedule on track.
>>
>> Once again, thanks everyone for the understanding.
>>
>> On 2026/04/07 19:44:17 Wei ZHOU wrote:
>> > Hi all,
>> >
>> > Due to several factors - such as the number of ongoing improvements and
>> new
>> > features, the significant QA effort required, and pending security
>> issues -
>> > we have decided to adjust the timeline. All dates will be postponed by
>> one
>> > month.
>> >
>> > The updated timeline of 4.23.0.0 release is as follows:
>> >
>> >    - *Until June 1st, 2026*: Accept new features, bug fixes, and
>> >    improvements
>> >    - *June 2nd, 2026*: Freeze the main branch. From this point onward,
>> only
>> >    critical/blocker fixes will be accepted
>> >    - *June 3rd, 2026*, or once all blocker/critical/security issues are
>> >    resolved (whichever is later): Cut RC1 and start the voting process
>> (allow
>> >    1-3 weeks for additional RCs if necessary)
>> >
>> >
>> > Thanks for your understanding and collaboration.
>> >
>> >
>> > Kind regards,
>> > Wei & Fabricio
>> >
>> >
>> >
>> >
>> > On Tue, Feb 3, 2026 at 9:11 AM Wei ZHOU <us...@gmail.com> wrote:
>> >
>> > > Hi all,
>> > >
>> > > We are planning to work on a CloudStack 4.23.0 release.
>> > >
>> > > CloudStack 4.23.0 will be a Regular release [1], which introduces new
>> > > features
>> > > and enhancements.  It is targeted for users who require the newest
>> > > features as
>> > > early as possible and are able to upgrade when the releases are
>> available.
>> > >
>> > > As discussed [2], I'll serve as the RM for the 4.23.0 release.
>> Fabricio
>> > > Duarte will
>> > > act as the co-RM, assisting with triage, reviews, testing, merges,
>> etc and
>> > > release work.
>> > >
>> > > The timeline for this would be the following (Proposed by Fabricio,
>> > > thanks):
>> > >
>> > > - Until May 3rd 2026: accept new features, bug fixes and improvements.
>> > > - May 4th 2026: freeze the main branch. From this point, we would only
>> > > accept
>> > > critical/blocker fixes.
>> > > - May 11th 2026: cut RC1 and start the vote (1-3 weeks to work on the
>> next
>> > > RCs if necessary).
>> > >
>> > > All open issues and PRs targeted for this release are tracked in the
>> > > 4.23.0
>> > > release milestone [3]. The design document of some features can be
>> found
>> > > at
>> > >
>> > >
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.23+Design+Documents
>> > >
>> > > Please ping us (@weizhouapache or @winterhazel) on your PRs and issues
>> > > that
>> > > are to be included in 4.23.0 on Github. Please let us know if you
>> have any
>> > > questions.
>> > >
>> > >
>> > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>> > > [2] https://lists.apache.org/thread/z7n339vcdym9f494ngb5pkzlxx8mjf2n
>> > > [3] https://github.com/apache/cloudstack/milestone/42
>> > >
>> > >
>> > > Kind regards,
>> > > Wei
>> > >
>> > >
>> >
>>
>