I understand all changes has to be landed on master first and that's fine, but active development for future releases (9.3 or 10.0) on master after branching 9.2.x increase the gap between the two and cherry-picking gets difficult day by day. "10-Dev" branch probably mitigate it, but I don't see reasons to keep 9.2.x unreleased for a long time after the branching. I think we should focus on stabilizing it and release 9.2.0 soon before it gets hard like 9.1.0 release. This is why I asked what the branching means and indirectly suggested calling a feature freeze.
What I'm trying to do with my review suspension for some PRs is prioritizing changes for next release. Changes for 10.x don't need to be reviewed today regardless of whether those are invasive / incompatible or not. Issues that have been there on 9.1.x releases don't necessarily have to be resolved on 9.2.x. Even a bug fix can make a new bug. What we need to do to stabilize 9.2.x is resolving issues that didn't exist on 9.1.x, such as regressions and bugs in new features on 9.2, and I'm going to review only those PRs until we release 9.2.0. If any of you wanted to annoy RM like we did for 9.1.0 release, request reviews from someone else ;-) Masakazu On Wed, Sep 29, 2021 at 7:31 AM Leif Hedstrom <zw...@apache.org> wrote: > > > > On Sep 28, 2021, at 3:37 AM, Masakazu Kitajo <mas...@apache.org> wrote: > > > > Can you clarify what branching 9.2.x means (again)? > > It means, branched from master -> 9.2.x. Going forward, anything that we > want in 9.2.x must be marked with “Project 9.2.x” (remember, Milestone is > still 10.0.0), and I will cherry pick those PRs which should go into 9.2.x. > > > I don't have a strong opinion on the release date, but I think RM should > > clearly call a feature freeze sooner rather than later and we all should > > focus on stabilizing the branch because we already have many changes for > > 9.2.0. > > Agreed. v9.2.x is not “feature frozen” yet, but will be. We can certainly > pick a hard date for this if that’s the community concsent? > > > > I'm personally going to suspend reviewing PRs for 10.0, PRs that try to > add > > new features to 9.x, and PRs that try to resolve issues on previous > > releases (except security issues). > > Hmmm, what PRs does that leave then? ;-). Everyone should review all > 10.0.x (master) PRs, only those PRs landed on master would ever be > considered going into any 9.x release. I can understand not reviewing PRs > going into “10-Dev”, those are the invasive / incompatible PRs that we want > for 10.0.0, but which can not go into 9.x. > > Cheers, > > — Leif > > > > > Masakazu > > > > On Sat, Sep 18, 2021 at 1:52 AM Leif Hedstrom <zw...@apache.org> wrote: > > > >> Hi all, > >> > >> I’m going to branch v9.2.x, from current master, Monday morning, 9/20. > We > >> will continue development on v9.2.0 of course, but remember that you > will > >> need to mark PRs with “Project 9.2.x” for consideration into the > upcoming > >> branch. I’d like to aim to have a v9.2.0 release either late November / > >> early December, or possibly early January 2022. Please discuss if you > have > >> a preference here. > >> > >> Cheers, > >> > >> — Leif > >> > >> > >
