Hi,
In <CAGvDy=o3ohs5lfhqvre3r0mo1if7o908v6wd_oy0aqv5sdt...@mail.gmail.com>
"Re: [DISC][Release] More control on Release Candidates commits" on Tue, 10
May 2022 13:27:09 +0200,
Raul Cumplido <[email protected]> wrote:
> I still think there is some value in standardising the "feature freeze" on
> new release candidates once a first release candidate has been created and
> only add required fixes for the follow up RCs. What I would like to avoid
> with that is rushing big new features at the end that might be added
> between release candidates.
>
>>> PROBLEM 1: Rush period before the release:
>>
> The only proposal I can think of around this is that I will try and share
> the release schedule earlier. I sent an email [2] with a ~1.5/~2 weeks
> notice, maybe if all of us start being more aware that a release is coming
> with a little more time (1 month) we can plan better.
How about releasing more frequently? If we release a new
version frequently, stakeholders will be able to wait for
future releases instead of pushing a new feature to the next
release. If we release a new version in the middle of even
months, how about the following schedule?
1. Set release target date (e.g. 2022-08-10/20 for 9.0.0)
2. Notice release target date at 2022-07-01
(We can automate this.)
3. Create a release branch for the next version (release-9.0.0) and
use the next next version (10.0.0) as the default version
for dev/merge_arrow_pr.py at 2022-08-01
(We can automate this.)
4. Stabilize release-9.0.0 branch in 2022-08-01/10
("feature freeze")
(We should verify this branch by our nightly CI.)
5. Vote and release 9.0.0 in 2022-08-10/20
6. Set release target date (e.g. 2022-10-10/20 for 10.0.0)
7. ...
Thanks,
--
kou
