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
>
