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]
