+1 I support this timeline. > I also wanted to propose trying out a model where we have 3 release > managers for all major releases.
Great idea, this will be a valuable improvement to our release process. It also creates an opportunity for new committers to ease into the release management role. Thanks, Michael On Fri, Feb 17, 2023 at 4:44 PM Matteo Merli <mme...@apache.org> wrote: > > Since the LTS release model has been formally approved, I'm proposing > the following schedule for the release: > > * Tue - 2023-05-11 > - RC-1 > - Code Freeze -- Only critical fixes will be merged in the 3.0 > release branch. Contributors should plan to have all the changes merged in > before this date. Exceptions should be extremely rare and strongly > motivated. > > * Tue - 2023-05-18 - RC-2 > * Tue - 2023-05-25 - RC-3 > * Tue - 2023-05-02 - Announce 3.0 Release > > These dates will be published on the website to present users with a > "roadmap" and we should commit to and respect these dates. > > I also wanted to propose trying out a model where we have 3 release > managers for all major releases. > > The reasoning behind this is for this small group of people to collaborate > and divide the tasks for the release: merging patches from the "master" > branch, preparing RC, and testing. > > Since everyone also has other work duties and unexpected tasks that can pop > up at any time, it will help to have redundancy in the release-management > "team", so that we can release on the exact dates. > > Thanks, > Matteo > > -- > Matteo Merli > <mme...@apache.org>
