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]
