Updates: we still have the same problems as discussed in this mail thread: https://lists.apache.org/thread/w45ykt47omcqc672tn6vhdkx7fnfydmw. When one PR includes 100+ commits, the `Rebase and merge` and other buttons cannot work. So we need to proceed with CLI.
Plan to merge these commits today, following the commands below on a clean workdir: ``` git clone https://github.com/apache/cloudberry.git cd cloudberry git fetch origin pull/1547/head:cp_main git checkout cp_main git rebase origin/REL_2_STABLE git checkout REL_2_STABLE git pull origin REL_2_STABLE git merge cp_main --no-ff git push origin REL_2_STABLE ``` If something is wrong, please let me know. Thanks! Best, Dianjin Wang On Wed, Jan 28, 2026 at 10:52 PM Dianjin Wang <[email protected]> wrote: > > Thanks Wei. The PR should be https://github.com/apache/cloudberry/pull/1547. > Left my comments. Let’s work together to move forward! > > On Wednesday, January 28, 2026, 韩伟 <[email protected]> wrote: >> >> Hi all, >> The latest commits from the main branch have been integrated into the >> REL_2_STABLE branch via cherry-pick. All CI checks passed. Would appreciate >> more reviews and feedback from the community before moving >> forward. >> >> Best, wei han >> > From: "Dianjin Wang"<[email protected]> >> > Date: Tue, Jan 13, 2026, 18:02 >> > Subject: Re: [DISCUSS] Apache Cloudberry 2.1.0 release >> > To: "[email protected]"<[email protected]> >> > Hi all, >> > >> > Quick update on PR #1522: the binary swap test is now passing >> > successfully in CI, and the current results look good. Would >> > appreciate more reviews and feedback from the community before moving >> > forward. >> > >> > PR link: https://github.com/apache/cloudberry/pull/1522. >> > >> > Thanks a lot for your time and help! >> > >> > Best, >> > Dianjin Wang >> > >> > On Fri, Jan 9, 2026 at 10:16 AM Dianjin Wang <[email protected]> wrote: >> > > >> > > Hi, >> > > >> > > The PR is still in progress and needs more work. Thanks for your >> > > comment. I will share more details on GitHub. >> > > >> > > For introducing commits from main to REL_2_STABLE, both approaches sound >> > > workable. Your way is more efficient than cherry-picking and keeps the >> > > commit SHA unchanged. Maybe we can try your way first. Only a few >> > > commits need to be reverted or updated. (The breakable PRs were labeled, >> > > so they were figured out more easily.) >> > > >> > > >> > > On Friday, January 9, 2026, Leonid Borchuk <[email protected]> wrote: >> > >> >> > >> Hi! >> > >> >> > >> +1 for the catalog compatibility check. >> > >> >> > >> Also, I see you have created >> > >> https://github.com/apache/cloudberry/pull/1522, >> > >> where we can check if all the tests pass for both old and new binaries. >> > >> This >> > >> should check both the catalog compatibility and correct working with >> > >> stored >> > >> data. >> > >> >> > >> By the way, I realized that you proposed cherry-picking a set (series) >> > >> of >> > >> commits from the main branch to the REL_2_STABLE. >> > >> >> > >> I used to want to save effort and thought we could sync the main with >> > >> REL_2_STABLE and then revert commits breaking catalog compatibility. But >> > >> it's hard to implement, and there may be several such commits. And we >> > >> should create a reverting commit(s) (which could be challenging). >> > >> >> > >> So, your proposal for cherry-picking commits is more appealing to me. >> > >> And we >> > >> could also check them in the workflow and make sure everything works as >> > >> expected. Let's do it this way. >> > >> >> > >> WBW, Leonid. >> > >> >> > >> On Tue, Jan 6, 2026 at 6:31 AM Dianjin Wang <[email protected]> >> > >> wrote: >> > >> >> > >> > Hi all, >> > >> > >> > >> > Happy New Year, and best wishes for 2026! 🎉 >> > >> > >> > >> > I’d like to follow up on the earlier thread and suggest that we >> > >> > revisit the discussion about the Apache Cloudberry 2.1.0 release. From >> > >> > a user perspective, having a 2.1 release on top of 2.0 is quite >> > >> > important, as it allows users to benefit from incremental improvements >> > >> > and bug fixes without waiting too long for a larger release. >> > >> > >> > >> > To move this forward, I think there are two key points we should >> > >> > align on: >> > >> > >> > >> > 1. CI coverage for the `REL_2_STABLE` branch >> > >> > >> > >> > We should invest in proper CI for the release branch. For changes >> > >> > flowing from `main` to `REL_2_STABLE`, it may be safer to go through >> > >> > PRs rather than direct pushes, so that changes are visible and >> > >> > properly validated. >> > >> > >> > >> > From an implementation standpoint, we can likely reuse most (or all) >> > >> > of the existing CI workflows from main by simply extending them to >> > >> > also run on the release branch. >> > >> > >> > >> > 2. Upgrade path from 2.0 to 2.1 >> > >> > >> > >> > As discussed before, we should ensure that users can upgrade from 2.0 >> > >> > to 2.1 as smoothly as possible. Ideally, this means supporting a >> > >> > direct binary-replacement-style upgrade, without data migration. >> > >> > >> > >> > To gain confidence here, we may need to establish something similar to >> > >> > an ABI (or catalog compatibility) testing mechanism, so we can clearly >> > >> > define and validate the upgrade guarantees we provide. >> > >> > >> > >> > Glad to hear everyone’s thoughts on these points and whether it makes >> > >> > sense. Looking forward to the discussion. >> > >> > >> > >> > BTW, we can certainly continue this discussion into next week to allow >> > >> > everyone time to catch up after the New Year holidays. >> > >> > >> > >> > Best, >> > >> > Dianjin Wang >> > >> > >> > >> > On Wed, Oct 22, 2025 at 8:42 PM Lirong Jian <[email protected]> >> > >> > wrote: >> > >> > > >> > >> > > Yes, we definitely should have a 2.1 release with all bug fixes and >> > >> > > improvements except those related to catalog changes, since the >> > >> > > branch >> > >> > > associated with the 2.0.0 version is sort of too old. >> > >> > > >> > >> > > Best, >> > >> > > Lirong >> > >> > > >> > >> > > >> > >> > > Dianjin Wang <[email protected]> 于2025年10月21日周二 15:58写道： >> > >> > > >> > >> > > > On Mon, Oct 20, 2025 at 11:50 PM Leonid Borchuk >> > >> > > > <[email protected]> >> > >> > > > wrote: >> > >> > > > > >> > >> > > > > Indeed, ./postgres --catalog-version for 2.0.0-incubating takes >> > >> > > > > us >> > >> > > > > Catalog version number: 302502091 >> > >> > > > > >> > >> > > > > while current HEAD - 302509031 >> > >> > > > > >> > >> > > > > So it's impossible to migrate from 2.0.0 to the current HEAD. >> > >> > > > > Users >> > >> > > > should >> > >> > > > > create a new cluster and then use cbcopy to move all data. >> > >> > > > > Which is >> > >> > not a >> > >> > > > > minor change. >> > >> > > > > >> > >> > > > > Maybe we should create 2.1 without changes in catalog and then >> > >> > > > > merge >> > >> > all >> > >> > > > > our fixes and release version 3.0 ? >> > >> > > > >> > >> > > > Yes, the main branch catalog has been changed. The version has >> > >> > > > been >> > >> > > > bumped to 3.0.0 in the main. >> > >> > > > >> > >> > > > Additionally, I believe that one goal of the 2.1 release is to >> > >> > > > allow >> > >> > > > users to upgrade their 2.0 simply by swapping the binary, without >> > >> > > > requiring data migration. >> > >> > > > >> > >> > > > --------------------------------------------------------------------- >> > >> > > > 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] >> > >> > >> > >> > >> > > >> > > >> > > >> > > -- >> > > >> > > >> > > Best, >> > > Dianjin Wang >> > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > > > > > -- > > > Best, > Dianjin Wang > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
