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] > >
