Hmm... Good questions. I assumed we'd do a 5.1.2 pretty quickly. The time between the minor branches is waaayyyy too long.
I think might be fairly simple: Bug fixes have to be able to land somewhere. And that somewhere should not be tied to new features. So, until we have a release on the next minor version we do patches on the current minor release. I.e. we have no 5.2 release - and frankly who knows when we'll have that. So until then we should do 5.1.x releases. Once we have a 5.2.x release, it's up to whether we'll find a maintainer for the 5.1 branch. Not sure I can trust jira now, but we currently have 16 5.1.2 changes. Might be time to do a patch release again. (Some are somewhat important for the Trino integration) Here's a query that finds issues against 5.2.0 that are also in 4.16.1, 4.16.2, or 4.17.0 but not in 5.1.2 or 5.1.1. https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20fixVersion%20%3D%205.2.0%20and%20(fixVersion%20%3D%204.16.1%20or%20fixVersion%20%3D%204.16.2%20or%20fixVersion%20%3D%204.17.0)%20and%20fixVersion%20!%3D%205.1.2%20and%20fixVersion%20!%3D%205.1.1 Returns 17 issues for me, including 10 marked as resolved. PHOENIX-6457 Geoffrey Jacoby 4.17.0, 5.2.0 Reopened Actions PHOENIX-6454 Swaroopa Kadam 4.17.0, 5.2.0 Open Actions PHOENIX-6451 Richárd Antal 4.17.0, 5.2.0 Resolved Actions PHOENIX-6447 Sandeep Pal 4.16.1, 4.17.0, 5.2.0 Resolved Actions PHOENIX-6444 Rushabh Shah 4.17.0, 5.2.0 Resolved Actions PHOENIX-6437 Ankit Jain 4.17.0, 5.2.0, 4.16.2 Resolved Actions PHOENIX-6435 Xinyi Yan 4.16.1, 4.17.0, 5.2.0 Resolved Actions PHOENIX-6430 Jacob Isaac 4.17.0, 5.2.0 Resolved Actions PHOENIX-6429 Jacob Isaac 4.17.0, 5.2.0 Resolved Actions PHOENIX-6420 Tanuj Khurana 4.17.0, 5.2.0 Resolved Actions PHOENIX-6399 Istvan Toth 4.17.0, 5.2.0 Resolved Actions PHOENIX-6397 vikas meka 4.17.0, 5.2.0 In Progress Actions PHOENIX-6395 vikas meka 4.17.0, 5.2.0 In Progress Actions PHOENIX-6379 vikas meka 4.17.0, 5.2.0 Resolved Actions PHOENIX-6227 Geoffrey Jacoby 4.17.0, 5.2.0 Open Actions PHOENIX-6085 Richárd Antal 4.17.0, 5.2.0 Patch Available Actions PHOENIX-5346 Unassigned 4.17.0, 5.2.0 Reopened Actions Maybe the owners can have a quick look. Cheers. -- Lars On Wednesday, May 12, 2021, 10:42:58 PM PDT, Istvan Toth <[email protected]> wrote: 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 <[email protected]> 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 [email protected] <[email protected]> > 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 [email protected] <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/ > ------------------------------
