I’ve been looking at how other Apache Incubator projects handle release votes, and noticed that some projects run a single vote covering the main repository together with related sub-project repositories. E,g.: https://lists.apache.org/thread/zyy4v8ky3w5tb0ypgjyhzxs05fv2l2gy.
I’m wondering whether this could be an option for Cloudberry as well for the upcoming release. Could our mentors please help confirm whether this approach is allowed and appropriate? Thanks! Best, Dianjin Wang On Mon, Feb 2, 2026 at 9:39 PM Dianjin Wang <[email protected]> wrote: > > 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/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] >> > >> > > > > > -- > > > Best, > Dianjin Wang > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
