Great, I think we can proceed this way.
While we are on this, what are your thoughts on the timeline I proposed
originally for the release?
On 12/16/25 10:34, Wei ZHOU wrote:
Hi Fabricio,
Thank you !
I appreciate your openness and willingness to support.
I would also be happy to serve as the RM for the 4.23 release.
If you’re comfortable with it, we can certainly have you involved in the
discussions and ongoing updates, so you can get familiar with the release
process and contribute where it makes sense.
Please feel free to share your thoughts, and thanks again
Kind regards,
Wei
On Tue, Dec 16, 2025 at 2:13 PM Fabricio Duarte <
[email protected]> wrote:
Hi Wei,
I am open to start with a minor release if that is what the community
thinks is better.
With that said, I am still available and would be happy to support the
RM for v23 in order to get used to the release process. Whoever takes on
the next major can ping me either on the Slack community or on GitHub if
there is anything that I can help with.
Regards,
Fabricio
On 12/15/25 15:28, Wei ZHOU wrote:
Hi Fabricio,
Thanks for volunteering.
Since this would be your first time in the RM role, it might be a great
opportunity to start with a minor release.
Would you be open to waiting and taking on the next minor release instead
(for example, 4.20.4 or 4.22.2)? This will help you get familiar with the
process.
What do you think?
Kind regards,
Wei
On Mon, Dec 15, 2025 at 12:49 PM Fabricio Duarte <
[email protected]> wrote:
Hey all,
I would like to volunteer as the RM for v23.
I do not have a previous experience managing the community's release,
but the guidelines linked by Daan seem clear enough for me. Also, I can
get support from other members of the community if needed.
My idea is to release v23 around the last week of May, so that we can
get 2 major versions in 2026 with around 6.5 months for the development
of each version. The timeline for this would be the following:
- Until May 3rd: accept new features, bug fixes and improvements.
- May 4th: freeze the main branch. From this point, we would only accept
critical/blocker fixes.
- May 11th: cut RC1 and start the vote (1-3 weeks to work on the next
RCs if necessary).
What does everyone think?
Regards,
Fabricio
On 2025/12/11 11:54:32 Daan Hoogland wrote:
> devs (and users), Call me impatient, but I don't want us falling
out of
> rhythm. We already have 'kind of' consensus on the next few
releases;
4.20.3
> , -22.1 and -23. Do people agree with that assessment? next question
> obviously being; are there any volunteers to take on the RM work for
those?
> (Being a PMC member helps but is definitely not a requirement, as
there
> will be plenty of support) And if you volunteer, what are the
timelines you
> would propose?
>
> my idea was:
> - 20.3 february
> - 22.1 march
> - 23 may , but the RM is to have a word in that of course
> The procedures around releases are a kind of tribal knowledge though
there
> are some guides[1][2][3]. It would help if you are also willing to
help
> kristalising and automating these; [1]
>
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Management+Guidelines%3A+Effective+CloudStack+Release+Manager
> [2]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>
> --
> Daan
>
