I've also wanted to bring this up after 5.1, but forgot while dealing with the problems in 5.1.0
Do we want to maintain patch branches ? For how long ? What do we want to commit to the maintenance branches ? Who commits to the maintenance branches ? To kickstart the discussion, here are my current assumptions, which are of course colored by the requirements at $dayjob: Do we want to maintain patch branches ? I think we should. Publishing patch releases that focus on bug fixes (and supporting new HBase releases) and help users in a big way. I believe that both large contributors maintain internal branches. Doing most of that work on the apache maintenance branches shouldn't be a lot of additional net effort. How long should we maintain patch branches ? I feel that maintaining them until we start the next minor release process is a good compromise. Of course this also assumes that we also make semi-regular patch releases on a 1-3 month cadence. Getting into the habit of doing a "final" patch release around the release of the next minor version would also be helpful for users. What do we want to commit to the maintenance branches ? NOTHING that breaks compatibility EVERY significant bug fix (for some definition of significant) For everything else, I personally make the decision based on effort: If it's a change that applies cleanly, and requires no additional work, I generally backport it. Who commits to the maintenance branch ? I like the current practice that the original committer should generally do it. Before starting the patch release RC process, the RM can compare the main branch and the maintenance branch, and backport the changes that the RM deems necessary. I have also been operating on the assumption that while the RC is open, only the RM should commit to the maintenance branch, but that's just me not wanting to interfere with Xinyi's work, and I'd be happy either way. regards István On Wed, May 12, 2021 at 10:21 PM Geoffrey Jacoby <gjac...@apache.org> wrote: > Have we actually decided that branch-5.1 will produce our next version of > Phoenix? > > I've been assuming that 4.16 (and 5.1, which I'll admit I forgot existed) > were just for bug fixes, and that the next significant version of Phoenix > would be 5.2 / 4.17 sometime in H2 of 2021. (Or potentially just 5.2, if > the "retire 4.x" proposal on another thread passes.) > > We already have several changes in 4.x and master that add columns to > System.Catalog and hence can't go out in 4.16.2 or 5.1.2. (See PHOENIX-6247 > -- which should be marked Resolved -- and PHOENIX-6457). > > Do we need the dual maintenance of a 5.1 patch branch? > > Geoffrey > > On Wed, May 12, 2021 at 12:55 PM la...@apache.org <la...@apache.org> > wrote: > > > Hi all, > > > > I noticed some changes that went into both master and the 4.x branch, but > > not into branch-5.1. > > > > Unfortunately I do not have time to check each edit. > > > > When you commit changes, please do not forget about branch-5.1, which > will > > produce our next version of Phoenix. > > > > Cheers. > > > > -- Lars > > > -- *István Tóth* | Staff Software Engineer st...@cloudera.com <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> <https://www.cloudera.com/> ------------------------------
