I think we need to make a final decision on this; otherwise our work will be blocked.
My +1 vote is to absorb PostgreSQL 14.4 → 14.20 (and future PG14 updates) into the current `main` branch first, and then cherry-pick the changes from `main` into `REL_2_STABLE`. We should not freeze the PG version that main is based on. If main cannot continuously track upstream improvements, we lose one of the key advantages of being a PostgreSQL downstream project. In other words, `main` should remain the `upstream` for `REL_x_STABLE`, not the other way around. Looking forward to more voices. Best, Dianjin Wang On Mon, Feb 9, 2026 at 10:54 PM Dianjin Wang <[email protected]> wrote: > > Hi, > >> >> 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). > > > Yes, agree. We set the main branch to 3.0 to reflect the catalog changes due > to only a few commits. > >> 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 a PG16-rebased version. > > > For now, I have no strong opinion on that 3.x will be a PG14-based or > PG16-based version. > > If PG16 work is done, +1 to merge the cbdb-merge-upstream to the main branch. > But strong suggest we have a main mirror branch like PG_14_Base/Main for > backup in case of unexpected situations > before merging the PG16 work. > > Just one question here: if we freeze the main, how can we do daily > development? Minor kernel upgrade is only a part of our work. We cannot > freeze all work. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
