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]
