You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Adam Monsen <me...@apache.org> on 2025/10/20 23:30:21 UTC
release process improvement (was: 🗳 1.13.0 for release)
Hi Arnold,
Good questions/feedback, thank you. I want to leverage your insight here
to improve the release process. I'll go into detail for posterity. I
imagine given your tenure on the project some of this will be review.
Here's specifically what I've asked folks to do while voting on a rc
(release candidate):
1. verify rc checksums and signatures
2. build Fineract from rc src artifact
3. run Fineract from the compiled rc bin artifact
This is detailed in our docs
<https://fineract.apache.org/docs/1.13.0/#_artifact_verification>. It
stems from ASF release approval policy
<https://www.apache.org/legal/release-policy.html#release-approval>:
/Before casting +1 binding votes, individuals are REQUIRED to
download all signed source code packages onto their own hardware,
verify that they meet all requirements of ASF policy on releases as
described below, validate all cryptographic signatures, compile as
provided, and test the result on their own platform./
We started formalizing all this about 7 months ago --Â for 1.10.1rc
<https://lists.apache.org/thread/cs5t0ho39ktg2jxr74dqd7fg9nyfcz3k>Â because
I had the exact same question you did: What does /test/Â mean in this
context?
First can we agree that verifying rc checksums and signatures and
building rc src artifact are all straightforward requirements?
If so, then we're back to the ambiguous: /test/. I read /test/ as: *Make
sure the binary rc artifact works*, for you, as you understand it
should. To be painfully explicit: Anticipate someone else will download
and run the binary once/if it is promoted to a release and do yourself
what they'll do, taking into account known issues. Not: Repeat what we
do in CI. We're not expecting voters do any functional testing against
the rc.
Hence, the new-ish "Tested: YES/NO/PARTIAL" section in rc vote emails.
*It's my interpretation of what the ASF says its projects must do*. And
I agree with James: "Tested" is not the right word here. "Verified"
would be better. I'll change that.
But I want to change more.
*Overall I think our release process is inefficient and robust*.
Especially when we all vote. It's one thing for a release manager to go
through the steps and it's not hard once you get the hang of it, but I
don't love the parts of the rc vote beyond everyone just sending their
+1/-1. *I'm confident we can make it more efficient and just as robust*,
still meeting ASF policy with less of, e.g., the manual rc verification
we now do and just a more sensible release process overall. Maybe with
some simple automation, but maybe not just that.
I want to have a meeting to gather ideas to streamline releases, because
y'all know things I don't and policy affects us all.
I'm not looking forward to onboarding the next release manager. I don't
want them to have to just repeat what I've done. I'd rather hand them
something wonderfully improved and say "hey look how easy we made your
job! just click RELEASE and you're good" or something like that. Heck,
maybe we won't need a release manager at all if we judo this creatively.
Plenty of projects ship robust releases far more often than we do.
Thoughts? Wanna meet up?
-Adam
On 10/20/25 12:16, Arnold Galovics wrote:
> +1 from me too, but when people say "tested", do we know what kind of
> testing is supposed to happen? I feel like we just have this feeling
> of the package being tested, but in reality it cannot be considered
> actual functional verification (if that's what's supposed to happen).
>
> In my mind, functional testing is part of the pipeline and every
> commit making into the develop branch has to pass all the tests, it's
> a quality gate. Therefore by logic, whatever commit we pick for
> releasing is passing the quality gates hence no need for manual
> testing. What am I missing?
( original "[FINERACT] [VOTE] 🗳 1.13.0 for release" thread
<https://lists.apache.org/thread/bm9cynvrvvb1mvp7pc05v1zy5zo4h0hs> )
( original "release process improvement" thread
<https://lists.apache.org/thread/f99mhvxg9l3wz17thmwonvgn6vyz05vq>Â )
Re: release process improvement (was: 🗳 1.13.0 for release)
Posted by Adam Monsen <am...@mifos.org>.
The meeting will be this Wednesday, October 29, at 1400 UTC. Invite
attached. Description:
This is a 30-minute meeting to (a) gather people and ideas and (b) kick off
Fineract release process improvement experiments.
join: https://meet.jit.si/2025-10-29FineractReleaseProcess (please test
device audio & video before call)
agenda & minutes during meeting:
https://pad.disroot.org/p/2025-10-29_Fineract_Release_Process (will be
moved to Fineract wiki after meeting)
Thank you!
-Adam
On Fri, Oct 24, 2025 at 3:13 PM Adam Monsen <am...@mifos.org> wrote:
> Hi tooling users!
>
> I've been doing the past few Apache Fineract
> <https://fineract.apache.org/> releases, and I'm working on improving our
> release process
> <https://lists.apache.org/thread/jk2qzjxc89hd1c8xzvhtmlbbj1m8ktbl>. I'm
> here hoping to to attract someone familiar with the ASF release process and
> the ATR tool to a short meeting I'm setting up. We're trying out the ATR
> tool so I think there's some overlap in our interests. The goal of the
> meeting is to get people and ideas together and kick off a few experiments.
>
> If you might be able to join us, please let me know (see below).
>
> Best and thanks,
> -Adam
>
> ---------- Forwarded message ---------
> From: Adam Monsen <am...@mifos.org>
> Date: Fri, Oct 24, 2025 at 3:01 PM
> Subject: Re: release process improvement (was: 🗳 1.13.0 for release)
> To: <de...@fineract.apache.org>
>
>
> Thanks Terence, James, and everyone! Great thoughts here. Let's meet up
> and keep this ball rolling. Please go to https://whenisgood.net/yd95b7h
> and let me know which days work for you. Please enter your name. Please
> also enter your preferred email address in the comment.
>
> Or just email me directly / off-list. I'll tally the results in 72hrs and
> send meeting invites. The day choices are:
>
> - Wed Oct 29
> - Thu Oct 30
> - Fri Oct 31
> - Mon Nov 3
> - Tue Nov 4
> - Wed Nov 5
>
> Start time will be 1400 UTC on the day we agree on. Start time is not
> affected by daylight savings -- it'll be 1400 UTC regardless. This is a 30
> minute meeting.
>
Fwd: release process improvement (was: 🗳 1.13.0 for release)
Posted by Adam Monsen <am...@mifos.org>.
Hi tooling users!
I've been doing the past few Apache Fineract <https://fineract.apache.org/>
releases, and I'm working on improving our release process
<https://lists.apache.org/thread/jk2qzjxc89hd1c8xzvhtmlbbj1m8ktbl>. I'm
here hoping to to attract someone familiar with the ASF release process and
the ATR tool to a short meeting I'm setting up. We're trying out the ATR
tool so I think there's some overlap in our interests. The goal of the
meeting is to get people and ideas together and kick off a few experiments.
If you might be able to join us, please let me know (see below).
Best and thanks,
-Adam
---------- Forwarded message ---------
From: Adam Monsen <am...@mifos.org>
Date: Fri, Oct 24, 2025 at 3:01 PM
Subject: Re: release process improvement (was: 🗳 1.13.0 for release)
To: <de...@fineract.apache.org>
Thanks Terence, James, and everyone! Great thoughts here. Let's meet up and
keep this ball rolling. Please go to https://whenisgood.net/yd95b7h and let
me know which days work for you. Please enter your name. Please also enter
your preferred email address in the comment.
Or just email me directly / off-list. I'll tally the results in 72hrs and
send meeting invites. The day choices are:
- Wed Oct 29
- Thu Oct 30
- Fri Oct 31
- Mon Nov 3
- Tue Nov 4
- Wed Nov 5
Start time will be 1400 UTC on the day we agree on. Start time is not
affected by daylight savings -- it'll be 1400 UTC regardless. This is a 30
minute meeting.
Re: release process improvement (was: 🗳 1.13.0 for release)
Posted by Adam Monsen <am...@mifos.org>.
The meeting will be this Wednesday, October 29, at 1400 UTC. Invite
attached. Description:
This is a 30-minute meeting to (a) gather people and ideas and (b) kick off
Fineract release process improvement experiments.
join: https://meet.jit.si/2025-10-29FineractReleaseProcess (please test
device audio & video before call)
agenda & minutes during meeting:
https://pad.disroot.org/p/2025-10-29_Fineract_Release_Process (will be
moved to Fineract wiki after meeting)
Thank you!
-Adam
On Fri, Oct 24, 2025 at 3:01 PM Adam Monsen <am...@mifos.org> wrote:
> Thanks Terence, James, and everyone! Great thoughts here. Let's meet up
> and keep this ball rolling. Please go to https://whenisgood.net/yd95b7h
> and let me know which days work for you. Please enter your name. Please
> also enter your preferred email address in the comment.
>
> Or just email me directly / off-list. I'll tally the results in 72hrs and
> send meeting invites. The day choices are:
>
> - Wed Oct 29
> - Thu Oct 30
> - Fri Oct 31
> - Mon Nov 3
> - Tue Nov 4
> - Wed Nov 5
>
> Start time will be 1400 UTC on the day we agree on. Start time is not
> affected by daylight savings -- it'll be 1400 UTC regardless. This is a 30
> minute meeting.
>
Re: release process improvement (was: 🗳 1.13.0 for release)
Posted by Adam Monsen <am...@mifos.org>.
Thanks Terence, James, and everyone! Great thoughts here. Let's meet up and
keep this ball rolling. Please go to https://whenisgood.net/yd95b7h and let
me know which days work for you. Please enter your name. Please also enter
your preferred email address in the comment.
Or just email me directly / off-list. I'll tally the results in 72hrs and
send meeting invites. The day choices are:
- Wed Oct 29
- Thu Oct 30
- Fri Oct 31
- Mon Nov 3
- Tue Nov 4
- Wed Nov 5
Start time will be 1400 UTC on the day we agree on. Start time is not
affected by daylight savings -- it'll be 1400 UTC regardless. This is a 30
minute meeting.
Re: release process improvement (was: 🗳 1.13.0 for release)
Posted by Terence Monteiro <te...@gmail.com>.
Hi James,
On Thu, Oct 23, 2025 at 3:40 AM James Dailey <ja...@gmail.com> wrote:
> Please note this —>
>
> https://news.apache.org/foundation/entry/apache-trusted-releases-platform-begins-second-alpha
>
> This is the ATR project I previously prepared. Rather than creating our
> own, we should piggyback on this.
>
Thanks for sharing this. I had watched Dave Fisher's interview on recent
tooling improvements he led as VP of Tooling at the ASF. This was recorded
at the Community Over Code event last month at Minneapolis by Rich Bowen.
I'm also on the tooling mailing list and my suggestion is to take the path
of least resistance. Use tools where available and don't reinvent the
wheel. Only when we start using the tools will we get to know if it helps
achieve our goals or whether there are gaps which we need to fill beyond
the available tooling. This is my intuition based on experience - many
tools are not one-size-fits-all.
-Terence
On Tue, Oct 21, 2025 at 7:33 AM Terence Monteiro <te...@gmail.com>
> wrote:
>
>> Hi Adam,
>>
>> Thanks for your detailed explanation and thoughts on the release process
>> and verification part and process for Committers and PMC members to vote on
>> the release. I'm interested in discussing how we can automate and
>> streamline the release process. My own approach this time was instead of
>> using one of my existing machines, spawn a VM specifically to build
>> fineract. Everything I did to build and verify the release involved
>> commands and zero mouse clicks. So I can see a path where by documenting
>> these steps and writing scripts, the process can be streamlined. If you
>> want to schedule a call, I'm interested.
>>
>> Regards,
>> Terence Monteiro.
>>
>>
>> On Tue, Oct 21, 2025 at 5:00 AM Adam Monsen <me...@apache.org> wrote:
>>
>>> Hi Arnold,
>>>
>>> Good questions/feedback, thank you. I want to leverage your insight here
>>> to improve the release process. I'll go into detail for posterity. I
>>> imagine given your tenure on the project some of this will be review.
>>>
>>> Here's specifically what I've asked folks to do while voting on a rc
>>> (release candidate):
>>>
>>> 1. verify rc checksums and signatures
>>> 2. build Fineract from rc src artifact
>>> 3. run Fineract from the compiled rc bin artifact
>>>
>>> This is detailed in our docs
>>> <https://fineract.apache.org/docs/1.13.0/#_artifact_verification>. It
>>> stems from ASF release approval policy
>>> <https://www.apache.org/legal/release-policy.html#release-approval>:
>>>
>>> *Before casting +1 binding votes, individuals are REQUIRED to download
>>> all signed source code packages onto their own hardware, verify that they
>>> meet all requirements of ASF policy on releases as described below,
>>> validate all cryptographic signatures, compile as provided, and test the
>>> result on their own platform.*
>>>
>>> We started formalizing all this about 7 months ago -- for 1.10.1rc
>>> <https://lists.apache.org/thread/cs5t0ho39ktg2jxr74dqd7fg9nyfcz3k> because
>>> I had the exact same question you did: What does *test* mean in this
>>> context?
>>>
>>> First can we agree that verifying rc checksums and signatures and
>>> building rc src artifact are all straightforward requirements?
>>>
>>> If so, then we're back to the ambiguous: *test*. I read *test* as: *Make
>>> sure the binary rc artifact works*, for you, as you understand it
>>> should. To be painfully explicit: Anticipate someone else will download and
>>> run the binary once/if it is promoted to a release and do yourself what
>>> they'll do, taking into account known issues. Not: Repeat what we do in CI.
>>> We're not expecting voters do any functional testing against the rc.
>>>
>>> Hence, the new-ish "Tested: YES/NO/PARTIAL" section in rc vote emails. *It's
>>> my interpretation of what the ASF says its projects must do*. And I
>>> agree with James: "Tested" is not the right word here. "Verified" would be
>>> better. I'll change that.
>>>
>>> But I want to change more.
>>>
>>> *Overall I think our release process is inefficient and robust*.
>>> Especially when we all vote. It's one thing for a release manager to go
>>> through the steps and it's not hard once you get the hang of it, but I
>>> don't love the parts of the rc vote beyond everyone just sending their
>>> +1/-1. *I'm confident we can make it more efficient and just as robust*,
>>> still meeting ASF policy with less of, e.g., the manual rc verification we
>>> now do and just a more sensible release process overall. Maybe with some
>>> simple automation, but maybe not just that.
>>>
>>> I want to have a meeting to gather ideas to streamline releases, because
>>> y'all know things I don't and policy affects us all.
>>>
>>> I'm not looking forward to onboarding the next release manager. I don't
>>> want them to have to just repeat what I've done. I'd rather hand them
>>> something wonderfully improved and say "hey look how easy we made your job!
>>> just click RELEASE and you're good" or something like that. Heck, maybe we
>>> won't need a release manager at all if we judo this creatively. Plenty of
>>> projects ship robust releases far more often than we do.
>>>
>>> Thoughts? Wanna meet up?
>>>
>>> -Adam
>>> On 10/20/25 12:16, Arnold Galovics wrote:
>>>
>>> +1 from me too, but when people say "tested", do we know what kind of
>>> testing is supposed to happen? I feel like we just have this feeling of the
>>> package being tested, but in reality it cannot be considered actual
>>> functional verification (if that's what's supposed to happen).
>>>
>>> In my mind, functional testing is part of the pipeline and every commit
>>> making into the develop branch has to pass all the tests, it's a quality
>>> gate. Therefore by logic, whatever commit we pick for releasing is passing
>>> the quality gates hence no need for manual testing. What am I missing?
>>>
>>> ( original "[FINERACT] [VOTE] 🗳 1.13.0 for release" thread
>>> <https://lists.apache.org/thread/bm9cynvrvvb1mvp7pc05v1zy5zo4h0hs> )
>>>
>>> ( original "release process improvement" thread
>>> <https://lists.apache.org/thread/f99mhvxg9l3wz17thmwonvgn6vyz05vq> )
>>>
>>
Re: release process improvement (was: 🗳 1.13.0 for release)
Posted by James Dailey <ja...@gmail.com>.
Please note this —>
https://news.apache.org/foundation/entry/apache-trusted-releases-platform-begins-second-alpha
This is the ATR project I previously prepared. Rather than creating our
own, we should piggyback on this.
On Tue, Oct 21, 2025 at 7:33 AM Terence Monteiro <te...@gmail.com>
wrote:
> Hi Adam,
>
> Thanks for your detailed explanation and thoughts on the release process
> and verification part and process for Committers and PMC members to vote on
> the release. I'm interested in discussing how we can automate and
> streamline the release process. My own approach this time was instead of
> using one of my existing machines, spawn a VM specifically to build
> fineract. Everything I did to build and verify the release involved
> commands and zero mouse clicks. So I can see a path where by documenting
> these steps and writing scripts, the process can be streamlined. If you
> want to schedule a call, I'm interested.
>
> Regards,
> Terence Monteiro.
>
>
> On Tue, Oct 21, 2025 at 5:00 AM Adam Monsen <me...@apache.org> wrote:
>
>> Hi Arnold,
>>
>> Good questions/feedback, thank you. I want to leverage your insight here
>> to improve the release process. I'll go into detail for posterity. I
>> imagine given your tenure on the project some of this will be review.
>>
>> Here's specifically what I've asked folks to do while voting on a rc
>> (release candidate):
>>
>> 1. verify rc checksums and signatures
>> 2. build Fineract from rc src artifact
>> 3. run Fineract from the compiled rc bin artifact
>>
>> This is detailed in our docs
>> <https://fineract.apache.org/docs/1.13.0/#_artifact_verification>. It
>> stems from ASF release approval policy
>> <https://www.apache.org/legal/release-policy.html#release-approval>:
>>
>> *Before casting +1 binding votes, individuals are REQUIRED to download
>> all signed source code packages onto their own hardware, verify that they
>> meet all requirements of ASF policy on releases as described below,
>> validate all cryptographic signatures, compile as provided, and test the
>> result on their own platform.*
>>
>> We started formalizing all this about 7 months ago -- for 1.10.1rc
>> <https://lists.apache.org/thread/cs5t0ho39ktg2jxr74dqd7fg9nyfcz3k> because
>> I had the exact same question you did: What does *test* mean in this
>> context?
>>
>> First can we agree that verifying rc checksums and signatures and
>> building rc src artifact are all straightforward requirements?
>>
>> If so, then we're back to the ambiguous: *test*. I read *test* as: *Make
>> sure the binary rc artifact works*, for you, as you understand it
>> should. To be painfully explicit: Anticipate someone else will download and
>> run the binary once/if it is promoted to a release and do yourself what
>> they'll do, taking into account known issues. Not: Repeat what we do in CI.
>> We're not expecting voters do any functional testing against the rc.
>>
>> Hence, the new-ish "Tested: YES/NO/PARTIAL" section in rc vote emails. *It's
>> my interpretation of what the ASF says its projects must do*. And I
>> agree with James: "Tested" is not the right word here. "Verified" would be
>> better. I'll change that.
>>
>> But I want to change more.
>>
>> *Overall I think our release process is inefficient and robust*.
>> Especially when we all vote. It's one thing for a release manager to go
>> through the steps and it's not hard once you get the hang of it, but I
>> don't love the parts of the rc vote beyond everyone just sending their
>> +1/-1. *I'm confident we can make it more efficient and just as robust*,
>> still meeting ASF policy with less of, e.g., the manual rc verification we
>> now do and just a more sensible release process overall. Maybe with some
>> simple automation, but maybe not just that.
>>
>> I want to have a meeting to gather ideas to streamline releases, because
>> y'all know things I don't and policy affects us all.
>>
>> I'm not looking forward to onboarding the next release manager. I don't
>> want them to have to just repeat what I've done. I'd rather hand them
>> something wonderfully improved and say "hey look how easy we made your job!
>> just click RELEASE and you're good" or something like that. Heck, maybe we
>> won't need a release manager at all if we judo this creatively. Plenty of
>> projects ship robust releases far more often than we do.
>>
>> Thoughts? Wanna meet up?
>>
>> -Adam
>> On 10/20/25 12:16, Arnold Galovics wrote:
>>
>> +1 from me too, but when people say "tested", do we know what kind of
>> testing is supposed to happen? I feel like we just have this feeling of the
>> package being tested, but in reality it cannot be considered actual
>> functional verification (if that's what's supposed to happen).
>>
>> In my mind, functional testing is part of the pipeline and every commit
>> making into the develop branch has to pass all the tests, it's a quality
>> gate. Therefore by logic, whatever commit we pick for releasing is passing
>> the quality gates hence no need for manual testing. What am I missing?
>>
>> ( original "[FINERACT] [VOTE] 🗳 1.13.0 for release" thread
>> <https://lists.apache.org/thread/bm9cynvrvvb1mvp7pc05v1zy5zo4h0hs> )
>>
>> ( original "release process improvement" thread
>> <https://lists.apache.org/thread/f99mhvxg9l3wz17thmwonvgn6vyz05vq> )
>>
>
Re: release process improvement (was: 🗳 1.13.0 for release)
Posted by Terence Monteiro <te...@gmail.com>.
Hi Adam,
Thanks for your detailed explanation and thoughts on the release process
and verification part and process for Committers and PMC members to vote on
the release. I'm interested in discussing how we can automate and
streamline the release process. My own approach this time was instead of
using one of my existing machines, spawn a VM specifically to build
fineract. Everything I did to build and verify the release involved
commands and zero mouse clicks. So I can see a path where by documenting
these steps and writing scripts, the process can be streamlined. If you
want to schedule a call, I'm interested.
Regards,
Terence Monteiro.
On Tue, Oct 21, 2025 at 5:00 AM Adam Monsen <me...@apache.org> wrote:
> Hi Arnold,
>
> Good questions/feedback, thank you. I want to leverage your insight here
> to improve the release process. I'll go into detail for posterity. I
> imagine given your tenure on the project some of this will be review.
>
> Here's specifically what I've asked folks to do while voting on a rc
> (release candidate):
>
> 1. verify rc checksums and signatures
> 2. build Fineract from rc src artifact
> 3. run Fineract from the compiled rc bin artifact
>
> This is detailed in our docs
> <https://fineract.apache.org/docs/1.13.0/#_artifact_verification>. It
> stems from ASF release approval policy
> <https://www.apache.org/legal/release-policy.html#release-approval>:
>
> *Before casting +1 binding votes, individuals are REQUIRED to download all
> signed source code packages onto their own hardware, verify that they meet
> all requirements of ASF policy on releases as described below, validate all
> cryptographic signatures, compile as provided, and test the result on their
> own platform.*
>
> We started formalizing all this about 7 months ago -- for 1.10.1rc
> <https://lists.apache.org/thread/cs5t0ho39ktg2jxr74dqd7fg9nyfcz3k> because
> I had the exact same question you did: What does *test* mean in this
> context?
>
> First can we agree that verifying rc checksums and signatures and building
> rc src artifact are all straightforward requirements?
>
> If so, then we're back to the ambiguous: *test*. I read *test* as: *Make
> sure the binary rc artifact works*, for you, as you understand it should.
> To be painfully explicit: Anticipate someone else will download and run the
> binary once/if it is promoted to a release and do yourself what they'll do,
> taking into account known issues. Not: Repeat what we do in CI. We're not
> expecting voters do any functional testing against the rc.
>
> Hence, the new-ish "Tested: YES/NO/PARTIAL" section in rc vote emails. *It's
> my interpretation of what the ASF says its projects must do*. And I agree
> with James: "Tested" is not the right word here. "Verified" would be
> better. I'll change that.
>
> But I want to change more.
>
> *Overall I think our release process is inefficient and robust*.
> Especially when we all vote. It's one thing for a release manager to go
> through the steps and it's not hard once you get the hang of it, but I
> don't love the parts of the rc vote beyond everyone just sending their
> +1/-1. *I'm confident we can make it more efficient and just as robust*,
> still meeting ASF policy with less of, e.g., the manual rc verification we
> now do and just a more sensible release process overall. Maybe with some
> simple automation, but maybe not just that.
>
> I want to have a meeting to gather ideas to streamline releases, because
> y'all know things I don't and policy affects us all.
>
> I'm not looking forward to onboarding the next release manager. I don't
> want them to have to just repeat what I've done. I'd rather hand them
> something wonderfully improved and say "hey look how easy we made your job!
> just click RELEASE and you're good" or something like that. Heck, maybe we
> won't need a release manager at all if we judo this creatively. Plenty of
> projects ship robust releases far more often than we do.
>
> Thoughts? Wanna meet up?
>
> -Adam
> On 10/20/25 12:16, Arnold Galovics wrote:
>
> +1 from me too, but when people say "tested", do we know what kind of
> testing is supposed to happen? I feel like we just have this feeling of the
> package being tested, but in reality it cannot be considered actual
> functional verification (if that's what's supposed to happen).
>
> In my mind, functional testing is part of the pipeline and every commit
> making into the develop branch has to pass all the tests, it's a quality
> gate. Therefore by logic, whatever commit we pick for releasing is passing
> the quality gates hence no need for manual testing. What am I missing?
>
> ( original "[FINERACT] [VOTE] 🗳 1.13.0 for release" thread
> <https://lists.apache.org/thread/bm9cynvrvvb1mvp7pc05v1zy5zo4h0hs> )
>
> ( original "release process improvement" thread
> <https://lists.apache.org/thread/f99mhvxg9l3wz17thmwonvgn6vyz05vq> )
>