On Wed, May 11, 2022 at 6:01 AM Sutou Kouhei <[email protected]> wrote:
>
> 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?
That looks like a plan!
I had a similar idea to be stricter about the release dates + a
feature freeze period, but wasn't thinking of more frequent releases
which is a nice trade-off.
> 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.)
We may need more notices 2 weeks and 1 week before the feature freeze.
> 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.)
We should move the crossbow job triggers and reports to apache/arrow
so we have a tighter control over the nightlies.
> 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
