The reason we used to have an RM for the whole life of a major release is because we used to cut a single release branch and then build all of the releases off of that. We would cut a 2.x or 3.x branch and then create a tag at the 3.0 release. We would then backport whatever changes we wanted in 3.1 to the 3.x branch and then tag 3.1 from there. This meant that a single RM "owned" the branch for the duration of the Major release. Since we are moving to a model where we are cutting from master for each release, I think it makes sense that we could, if we wanted to, have a different RM for each release whether it is major or minor.
Whether or not we get enough volunteers still remains to be seen, I hope we will :) So, +1 from me. It seems reasonable on the surface. It's been a long time since I have had to RM though, back to the incubator days, so hopefully some of the more recent RMs (Rob, Derek, Rawlin) can chime in and let us know if we are missing something obvious here. Thanks, Dave On Mon, Apr 20, 2020 at 12:46 PM Jeremy Mitchell <mitchell...@apache.org> wrote: > For the last 2 major TC releases (3.x and 4.x) we've been appointing an > open source release manager for the entirety of the major release: > > 4.x - Rawlin > 3.x - Derek > > IMO this can be a lot of work if there are multiple minor releases inside a > major and can be quite a lengthy commitment for one person (sorry Derek and > Rawlin). How would everyone feel if we instead appointed release managers > for each release (minor or major)....and if we aim for quarterly releases, > this will limit the commitment to 3 months for a RM. The lower commitment > may also help in finding volunteers. > > Also, each release (major or minor) has it's own branch derived from > master, therefore, there's no reason you can't have different "branch > owners" of (for example): > > 5.0.x > 5.1.x > 5.2.x > > (fyi, a RM must be a TC committer) > > Thoughts? > > Jeremy >
