Hi! +1 for the long-life REL_x_STABLE branch and absorbing all bugfixes from PG14.4 → 14.20 changes. It's very important to have a long-running PG14-compatible cloudberry version.
But a question from Jinbao Chen is also relevant. May I rephrase it: What is the difference between REL_2_STABLE and REL_3_STABLE? There are several commits that change the catalog and need a new version of the catalog. But they don't add crucial functionality, so it makes no sense for users to migrate to REL_3_STABLE (migration is a very tedious process). If there is no crucial difference and PG16 rebasing is almost done, what if we freeze main and work on 14.4->14.20 in the REL_2_STABLE branch? All those (14.4->14.20) fixes should already be included in PG 16.11 or not relevant PG 16 branch. This will simplify the rebasing work, no need to fix merge conflicts once again. And REL_3X_STABLE will be PG16-rebased version. The version roadmap will be: REL_1X_STABLE - rebase PG14 REL_2X_STABLE - rebase GP7 && PG14.20 REL_3X_STABLE - rebase PG16 Which sounds rather solid and reflects the main milestones of database development. We will have different commits between main and REL_2_STABLE branches. But this reflects the postgres development peculiarities, we cannot fix it in our repo. On Mon, Feb 9, 2026 at 1:34 PM Dianjin Wang <[email protected]> wrote: > Let me further clarify my thinking (I also summarized it here for > reference: > https://gist.github.com/tuhaihe/17203f719634a5e8d2eca772d2220dc3). > > My main point is about branch hierarchy rather than the specific PG > version choice. > > Today, Cloudberry main is still PG14-based, so I think main should > remain the upstream integration branch for REL_x_STABLE. Ideally, > improvements (including PG14.4 → 14.20 changes) land in main first, > and then are backported to REL_2_STABLE, instead of the other way > around. > > Whether Cloudberry 3.x or 4.x is eventually based on PG14 or PG16 is > somewhat orthogonal to this discussion. The key is to keep the > upstream/downstream relationship clear: main should always be the base > branch for the current kernel line, and REL_x_STABLE should stay > downstream. > > This will help avoid branch inversion and long-term maintenance complexity. > > Best, > Dianjin Wang > > On Mon, Feb 9, 2026 at 5:30 PM Dianjin Wang <[email protected]> wrote: > > > > I have a slightly different understanding of our current branch model, > > and I’d like to clarify and share some thoughts for discussion. > > > > Today, Cloudberry main is not following the PostgreSQL master branch > > lineage. It is already a fork evolved from PostgreSQL 14.4 with many > > Cloudberry-specific changes. In this sense, our main branch is > > effectively a PG14-based product branch rather than an > > upstream-tracking branch. > > > > If we apply PG 14.4 → 14.20 changes only to REL_2_STABLE, one > > practical question is: > > when we release future versions from main, do we plan to cherry-pick > > those fixes back from REL_2_STABLE into main? Otherwise, main may > > diverge further from the stable branch in terms of correctness and > > security fixes, which could be hard to manage long-term. > > > > For the major kernel upgrade (PG16), one possible approach could be: > > * Keep the current PG14-based main as a maintenance branch (e.g., > > rename it to PG_14 or similar). > > * Promote the PG16-based branch (currently `cbdb-postgres-merge`) as > > the new main. > > * Cherry-pick Cloudberry-specific features and fixes from the PG14 > > branch into the PG16-based main to keep aligned before renaming these > > two branches. > > > > This way, the primary development line would move forward with PG16, > > and PG14 would stay in maintenance mode, which might reduce long-term > > non-linear merge conflicts. Then at last, we will have: > > - PG16 branch as main > > - PG_14 branch as maintenance branch > > - REL_2_STABLE as the 2.x branch (branch from PG_14) > > - REL_3_STABLE as the 3.x branch (branch from PG_14) > > - REL_4_STABLE as the 4.x branch (branch from PG16/main) > > > > I think it would be useful to align on a branching and upgrade policy > > early, as it will significantly affect future maintenance cost and > > contributor workflow. Just my thoughts for your reference. > > > > Best, > > Dianjin Wang > > > > On Mon, Feb 9, 2026 at 4:37 PM Jinbao Chen <[email protected]> > wrote: > > > > > > I believe the introduction of Postgres stable branch code should occur > on > > > Cloudberry's stable branches, > > > such as REL_2_STABLE. > > > > > > In theory, our main branch should only upgrade the code of the > PostgreSQL > > > master branch. Only after we switch to a > > > stable branch such as 'REL_2_STABLE' should we upgrade the code of the > > > PostgreSQL stable branch. > > > Introducing a large amount of code from the Postgres stable branch into > > > cloudberry/main will cause significant > > > problems for main version upgrades. The introduction of non-linear > codes > > > can cause intractable conflicts. > > > > > > I suggest this upgrade should be performed on REL_2_STABLE. > > > > > > > > > On Fri, Feb 6, 2026 at 6:20 PM Dianjin Wang <[email protected]> > wrote: > > > > > > > Cool! I created a GitHub Project: > > > > https://github.com/orgs/apache/projects/572/views/1, feel free to > > > > edit. > > > > > > > > Also agreed with your schema. Thanks! > > > > > > > > Best, > > > > Dianjin Wang > > > > > > > > On Fri, Feb 6, 2026 at 4:34 PM Kirill Reshke <[email protected] > > > > > > wrote: > > > > > > > > > > Here [0] is an old-style excel with all commits between 14.4 and > > > > > 14.20, just a list without any sort of analysis for now. > > > > > > > > > > I guess we can create github project for this upgrade process, and > > > > > have here tickets for each incremental step (14.4 - 14.5, 14.5 - > 14.6) > > > > > > > > > > So, we will use both [0] and github projects. > > > > > > > > > > Also, regarding the 2.x/3.x policy. I propose a scheme where > > > > > cherry-pick PR (which in turn can be a number of closely-related > > > > > commits) is always created for the main branch, reviewed and merged > > > > > here, and then Cloudberry committer, responsible for the PR simply > > > > > pushes changes to REL_2_x without addiniginal PR/review. Does it > > > > > sound? I think 14.4 - 14.20 commits are good in terms of code > quality > > > > > and ABI stability, so this might work. > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > [0] > > > > > https://docs.google.com/spreadsheets/d/1vjjEb39QPyXO-nDJZ0tHAtReIQKka0S2YnD2r1AFhkk/edit?gid=0#gid=0 > > > > > > > > > > On Fri, 6 Feb 2026 at 12:22, Kirill Reshke <[email protected] > > > > > > wrote: > > > > > > > > > > > > On Fri, 6 Feb 2026 at 09:13, Dianjin Wang <[email protected] > > > > > > wrote: > > > > > > > > > > > > > > Hi Kirill, > > > > > > > > > > > > > > On Thu, Feb 5, 2026 at 11:08 PM Kirill Reshke < > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > Sure > > > > > > > > This will in fact resolve many problems, not only CVE > > > > > > > > So, how do we organize this? Do we need big excel as in gpdb > > > > > > > > cherry-pick process? > > > > > > > > > > > > > > > > > > > > > > I think both approaches could work well — a shared Google > Sheet or a > > > > > > > GitHub Project/issue tracker. The key is to keep the progress > > > > > > > transparent and make it easy for others to participate and > > > > contribute. > > > > > > > > > > > > > > I want to share more ideas on the minior kernel upgrade for the > > > > reference. > > > > > > > > > > > > > > Between PG 14.4 and 14.20 there are ~1352 commits, so a phased > > > > upgrade > > > > > > > could be a reasonable approach. For example, upgrading > incrementally > > > > > > > (14.4 → 14.5 → 14.6, etc. ~100 commits per step) or grouping > several > > > > > > > minor versions per step could help keep the process more > controlled > > > > > > > and reduce risk. Curious to hear what others think. > > > > > > > > > > > > I don't have a strong opinion here. But to keep the Cloudberry > project > > > > > > more Postgres-y, let's try an incremental approach . > > > > > > > > > > > > > BTW, would you be interested in leading this upgrade effort, > if you > > > > > > > have the bandwidth? Having a coordinator would greatly help > drive > > > > this > > > > > > > forward. > > > > > > > > > > > > I would love to! But I'm a little inexperienced in the GitHub > > > > > > Project/issue tracker. Anyway I can cherry-pick for sure and > manage > > > > > > commit statuses/reviewing other people's PRs. > > > > > > > > > > > > > Best, > > > > > > > Dianjin Wang > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Kirill Reshke > > > > > > > > > > > > > > > > > > > > -- > > > > > Best regards, > > > > > Kirill Reshke > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
