I’d like to share an update on the documentation preparation for Apache Cloudberry 2.1. The build documentation for 2.1.0 has been updated and is now available here:
https://cloudberry.apache.org/docs/deployment/quick-build#for-apache-cloudberry-210-1 There are several notable changes compared to 2.0 releases: * New PAX dependency package A new dependency liburing-dev is introduced in 2.1 when building PAX. On older distributions (e.g., Ubuntu 20.04), users need to manually download and build the source package. * Environment script renamed The environment file has been renamed from greenplum_path.sh to cloudberry-env.sh. * Changes in default configure options * --enable-cassert has been removed from the default configuration, as it may significantly impact performance if users compile production builds with assertions enabled. * The default for PXF has been changed from --enable-pxf to --disable-pxf, aligned with the recent progress and restructuring in the cloudberry-pxf project. I tested these changes on Rocky 8+9 and Ubuntu 20.04 + 22.04, they worked well. If you notice any issues or missing details, please let me know. Love to have your feedback. Thanks! On Thursday, January 29, 2026, Max Yang <[email protected]> wrote: > Good news! > Looking forward to the release of 2.1.0 in the near future. > > Best regards, Max Yang > > > On Thu, Jan 29, 2026 at 5:27 PM Dianjin Wang <[email protected]> > wrote: > > > Updates: > > - PR #1547 has been merged into `REL_2_STABLE`. (Will summarize the > > CLI into the wiki for future reference.) > > > > Now I believe the codebase is ready for 2.1.0! > > > > > > Best, > > Dianjin Wang > > > > On Thu, Jan 29, 2026 at 2:43 PM Dianjin Wang <[email protected]> > > wrote: > > > > > > Updates: we still have the same problems as discussed in this mail > > > thread: https://lists.apache.org/thread/w45ykt47omcqc672tn6vhdkx7fnfyd > mw > > . > > > 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: dev-unsubscribe@cloudberry. > apache.org > > > >> > >> > 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] > > > > > -- Best, Dianjin Wang
