Hi, A quick update: the Release Runbook wiki page has now been prepared and is available here: https://github.com/apache/cloudberry/wiki/Release-Runbook
It documents the end-to-end release procedure, from starting the release discussion through publishing the final release, and can serve as a reference for the upcoming Apache Cloudberry 2.2 release. If any questions, suggestions, or find anything that could be improved, please feel free to reply here or reach out at any time. Feedback is always welcome. Best, Dianjin Wang On Thu, May 28, 2026 at 5:01 PM Dianjin Wang <[email protected]> wrote: > > One additional thought here: > > If some of these ecosystem-related changes (such as Rocky Linux 10 > support, yezzey, etc.) are going to land in the 2.x branch first, it > may make sense to cherry-pick recent main branch updates into > REL_2_STABLE sooner rather than later. This could help keep the > branches more aligned and reduce future cherry-pick/rebase conflicts. > > If anyone from the community would like to help with the sync work, > that would be greatly appreciated. > > If I'm not mistaken, @reshe has help cherry-pick twice since 2.1.0: > - https://github.com/apache/cloudberry/pull/1611 > - https://github.com/apache/cloudberry/pull/1616 > > > Best, > Dianjin Wang > > On Tue, May 26, 2026 at 11:12 AM Dianjin Wang <[email protected]> wrote: > > > > Hi Leonid, > > > > First of all, thanks for helping coordinate the 2.2.0 release > > discussion, taking the `release manager` role, and sharing the current > > progress and plans with the community. > > > > Regarding some of the points mentioned: > > > > - Kernel upgrade to 14.8 > > - Rocky Linux 10 support > > - Introducing yezzey support > > > > From the current status, these items all seem to require at least a > > few more weeks of work than we expected. Considering the ongoing PG16 > > kernel upgrade work discussion and the overall development/review > > cycle, we could certainly wait for them, and +1 to your idea that we > > can merge into 2.x branch first, then later adapt/rebase them onto the > > new main branch. (because I guess PG16 kernel merging will happen > > sooner than the work to be done.). This could also reduce some of the > > concerns from me during the PG16 transition. > > > > For the command center, I can help migrate the existing codebase into > > the Apache repository and provide a foundation for future development. > > It is difficult to make it fully ready for the 2.2 timeline. I don’t > > think we need to rush this part — once it is ready, we can always > > include it in a later release. > > > > Regarding cloudberry-go-libs, we already set up a basic CI workflow > > recently, optimized several parts of the build process, fixed some > > issues caused by Go version upgrades, and verified that the project > > can build and test successfully. For release validation: > > - From the compliance perspective, we can run: `mvn apache-rat:check` > > - From the functional perspective, we can manually run commands such > > as: `make depend`, `make unit` -- can add these ways to the README as > > a reference. > > We can also document these validation steps in the README as a > > reference for future releases. > > > > Thanks again! > > > > Best, > > Dianjin Wang > > > > On Tue, May 26, 2026 at 6:12 AM Leonid Borchuk <[email protected]> wrote: > > > > > > Hi all, > > > > > > Time flies. The last month has given us two without doubt milestones PRs > > > that will change everything. I mean, the new PG16-based kernel and the > > > logical transformations in the PostgreSQL optimizer. > > > > > > But before we have I think it's time to sum up our current progress. A > > > good > > > way to do this is by releasing our changes. > > > > > > So I'd like to commence discussing the Apache Cloudberry 2.2.0 release. > > > > > > This release will differ from previous ones in one very important aspect: > > > we will release the entire ecosystem at once. Together with the database > > > release, we will make a release to all related repositories, including not > > > only source files but also binary distributions for all supported > > > platforms. > > > > > > For today supported platforms is: > > > > > > > > > - Rocky Linux 8 > > > - Rocky Linux 9 > > > - Ubuntu 22.04 > > > - Ubuntu 24.04 > > > > > > Supported repostaries is: > > > > > > > > > - apache/cloudberry: main repo > > > - apache/cloudberry-backup: backup utility for Cloudberry. > > > - apache/cloudberry-go-libs: go-libs for Cloudberry. > > > - apache/cloudberry-pxf: Platform Extension Framework (PXF) for > > > Cloudberry. > > > > > > > > > Let’s discuss the possibility & possible timeline, scope, and any > > > preparations needed for the 2.2.0 release. Would like to have your > > > thoughts. > > > > > > > > > My list of questions and suggestions: > > > > > > 1. What will be the kernel of the new release? I think it should be 14.8, > > > but we're not ready yet - https://github.com/apache/cloudberry/pull/1701 > > > is > > > still under development.I believe in a couple of weeks we could complete > > > work. > > > > > > 2. Add rocky Linux 10 to the list of supported platforms. I've made > > > preparations but again, need a couple of weeks to add simple tests and > > > verify that everything is great. > > > > > > 3. Add command center to the list of supported repositories. So there will > > > be a simple UI to monitor installation. I honestly don't know how long it > > > will take, everything works but code needs to be added as an Apache > > > Repository. > > > > > > 4. Merge yezzey - https://github.com/apache/cloudberry/pull/1752 (still > > > under work, I believe again a couple of weeks and we will do it) > > > > > > 5. Decide if we want to wait for support for Java 21 in PXF or not. > > > https://github.com/apache/cloudberry-pxf/pull/109 > > > > > > 6. We want to publish cloudberry-go-libs as go project. Everything is > > > ready, we need to draft a new release, how to check it? > > > > > > > > > Some of the questions are related to the ecosystem and not related to the > > > main repository, but 2 and 4 are related, so if we don't want to wait and > > > delay > > > switching the main branch to a new kernel, it would be better to merge > > > them into > > > the 2x branch first and then into the main branch. > > > > > > > > > Best, > > > > > > Leonid Borchuk --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
