You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudberry.apache.org by Dianjin Wang <wa...@gmail.com> on 2026/10/05 08:12:00 UTC
[DISCUSS] Apache Cloudberry 3.0 release
Hi all,
I would like to propose that we start the release discussion for
Apache Cloudberry 3.0.
Cloudberry 3.0 will be the first release after the PostgreSQL 16
kernel upgrade. Starting the discussion early should give us clearer
guidance for completing the remaining work and coordinating the
release across the Cloudberry ecosystem.
Some initial items that may need to be addressed are:
1. Complete the PostgreSQL 16 kernel upgrade
There are still two items related to the PostgreSQL 16 upgrade on the
project board:
https://github.com/orgs/apache/projects/497
We should review their status and decide whether they are release
blockers for Cloudberry 3.0.
2. Port extensions and related ecosystem projects to Cloudberry 3.0
Some extensions introduced on `REL_2_STABLE`, such as `yezzey`, need
to be ported to the PostgreSQL 16-based codebase and verified on the
3.0 branch.
We should also review other extensions, tools, and components that may
require compatibility updates. The following projects may need to be
tested and released together with Cloudberry 3.0:
- cloudberry-backup
- cloudberry-pxf
- cloudberry-go-libs
- cloudberry-command-center (if possible?)
3. Decide the PostgreSQL minor version for Cloudberry 3.0
Given the scope and schedule of the 3.0 release, I propose using
PostgreSQL 16.9 as the baseline for Cloudberry 3.0 and planning the
upgrade to PostgreSQL 16.15 as part of Cloudberry 3.1.
4. Create the `REL_3_STABLE` branch
I suggest creating `REL_3_STABLE` from main after the 3.0 release
scope has been reviewed and the main remaining feature work has been
completed.
After the branch is created, we could use it for release stabilization
while continuing to merge general development work into main,
following the same approach as `REL_2_STABLE`.
5. Define the upgrade and compatibility strategy
Since Cloudberry 3.0 is based on PostgreSQL 16, we should explicitly
document and test the upgrade path from the previous Cloudberry
release, including:
- Upgrade limitations and known issues
- Upgrade documentation
- Compatibility of existing extensions and tools
- Support for Cloudberry 3.0 upgrades in tools such as `cbcopy`
I would be happy to serve as the Release Manager for Cloudberry 3.0
and coordinate the release planning, remaining development work, RC
preparation, and communication with related projects.
Please share your thoughts, concerns, and any additional release requirements.
Best,
Dianjin Wang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: dev-help@cloudberry.apache.org
Re: [DISCUSS] Apache Cloudberry 3.0 release
Posted by Dianjin Wang <wa...@gmail.com>.
For CI:
* We can introduce Meson build support in 3.0. I have a draft PR and
will try to get it ready for review.
* In addition, it's great to add support for Ubuntu 26.04 LTS,
including the 26.04 development Docker image and CI workflow support.
Best,
Dianjin Wang
On Mon, Oct 5, 2026 at 6:14 PM Leonid Borchuk <le...@gmail.com> wrote:
>
> Hi all, I'd like to add a couple of items here:
>
> 1.
>
> We also need fixes here to upgrade (gpupgrade, not copy) from REL_2_STABLE
> -> REL_3_STABLE
>
> And for upgrade from old GP5/GP6/GP7 versions to Cloudberry 3.0
>
> The latter (old GP) is an issue. To upgrade from it we need a set of
> commits, but the most controversial is
> https://github.com/open-gpdb/cloudberry/commit/13d90e77d16552d942bec8a375aae58a6f59b860
>
> We could fix gpupgrade utility later, but should merge all breaking catalog
> version patches before the release.
>
> 2. Anser && Datalake_fdw
>
> It will be great if we complete work and merge it. Ship together with other
> functionality. It's an opt-in option, so users should test it before usage.
>
> On Mon, Oct 5, 2026 at 11:13 AM Dianjin Wang <wa...@gmail.com> wrote:
>
> > Hi all,
> >
> > I would like to propose that we start the release discussion for
> > Apache Cloudberry 3.0.
> >
> > Cloudberry 3.0 will be the first release after the PostgreSQL 16
> > kernel upgrade. Starting the discussion early should give us clearer
> > guidance for completing the remaining work and coordinating the
> > release across the Cloudberry ecosystem.
> >
> > Some initial items that may need to be addressed are:
> >
> > 1. Complete the PostgreSQL 16 kernel upgrade
> >
> > There are still two items related to the PostgreSQL 16 upgrade on the
> > project board:
> > https://github.com/orgs/apache/projects/497
> >
> > We should review their status and decide whether they are release
> > blockers for Cloudberry 3.0.
> >
> > 2. Port extensions and related ecosystem projects to Cloudberry 3.0
> >
> > Some extensions introduced on `REL_2_STABLE`, such as `yezzey`, need
> > to be ported to the PostgreSQL 16-based codebase and verified on the
> > 3.0 branch.
> >
> > We should also review other extensions, tools, and components that may
> > require compatibility updates. The following projects may need to be
> > tested and released together with Cloudberry 3.0:
> >
> > - cloudberry-backup
> > - cloudberry-pxf
> > - cloudberry-go-libs
> > - cloudberry-command-center (if possible?)
> >
> > 3. Decide the PostgreSQL minor version for Cloudberry 3.0
> >
> > Given the scope and schedule of the 3.0 release, I propose using
> > PostgreSQL 16.9 as the baseline for Cloudberry 3.0 and planning the
> > upgrade to PostgreSQL 16.15 as part of Cloudberry 3.1.
> >
> > 4. Create the `REL_3_STABLE` branch
> >
> > I suggest creating `REL_3_STABLE` from main after the 3.0 release
> > scope has been reviewed and the main remaining feature work has been
> > completed.
> >
> > After the branch is created, we could use it for release stabilization
> > while continuing to merge general development work into main,
> > following the same approach as `REL_2_STABLE`.
> >
> > 5. Define the upgrade and compatibility strategy
> >
> > Since Cloudberry 3.0 is based on PostgreSQL 16, we should explicitly
> > document and test the upgrade path from the previous Cloudberry
> > release, including:
> >
> > - Upgrade limitations and known issues
> > - Upgrade documentation
> > - Compatibility of existing extensions and tools
> > - Support for Cloudberry 3.0 upgrades in tools such as `cbcopy`
> >
> > I would be happy to serve as the Release Manager for Cloudberry 3.0
> > and coordinate the release planning, remaining development work, RC
> > preparation, and communication with related projects.
> >
> > Please share your thoughts, concerns, and any additional release
> > requirements.
> >
> > Best,
> > Dianjin Wang
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > For additional commands, e-mail: dev-help@cloudberry.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: dev-help@cloudberry.apache.org
Re: [DISCUSS] Apache Cloudberry 3.0 release
Posted by Leonid Borchuk <le...@gmail.com>.
Hi all, I'd like to add a couple of items here:
1.
We also need fixes here to upgrade (gpupgrade, not copy) from REL_2_STABLE
-> REL_3_STABLE
And for upgrade from old GP5/GP6/GP7 versions to Cloudberry 3.0
The latter (old GP) is an issue. To upgrade from it we need a set of
commits, but the most controversial is
https://github.com/open-gpdb/cloudberry/commit/13d90e77d16552d942bec8a375aae58a6f59b860
We could fix gpupgrade utility later, but should merge all breaking catalog
version patches before the release.
2. Anser && Datalake_fdw
It will be great if we complete work and merge it. Ship together with other
functionality. It's an opt-in option, so users should test it before usage.
On Mon, Oct 5, 2026 at 11:13 AM Dianjin Wang <wa...@gmail.com> wrote:
> Hi all,
>
> I would like to propose that we start the release discussion for
> Apache Cloudberry 3.0.
>
> Cloudberry 3.0 will be the first release after the PostgreSQL 16
> kernel upgrade. Starting the discussion early should give us clearer
> guidance for completing the remaining work and coordinating the
> release across the Cloudberry ecosystem.
>
> Some initial items that may need to be addressed are:
>
> 1. Complete the PostgreSQL 16 kernel upgrade
>
> There are still two items related to the PostgreSQL 16 upgrade on the
> project board:
> https://github.com/orgs/apache/projects/497
>
> We should review their status and decide whether they are release
> blockers for Cloudberry 3.0.
>
> 2. Port extensions and related ecosystem projects to Cloudberry 3.0
>
> Some extensions introduced on `REL_2_STABLE`, such as `yezzey`, need
> to be ported to the PostgreSQL 16-based codebase and verified on the
> 3.0 branch.
>
> We should also review other extensions, tools, and components that may
> require compatibility updates. The following projects may need to be
> tested and released together with Cloudberry 3.0:
>
> - cloudberry-backup
> - cloudberry-pxf
> - cloudberry-go-libs
> - cloudberry-command-center (if possible?)
>
> 3. Decide the PostgreSQL minor version for Cloudberry 3.0
>
> Given the scope and schedule of the 3.0 release, I propose using
> PostgreSQL 16.9 as the baseline for Cloudberry 3.0 and planning the
> upgrade to PostgreSQL 16.15 as part of Cloudberry 3.1.
>
> 4. Create the `REL_3_STABLE` branch
>
> I suggest creating `REL_3_STABLE` from main after the 3.0 release
> scope has been reviewed and the main remaining feature work has been
> completed.
>
> After the branch is created, we could use it for release stabilization
> while continuing to merge general development work into main,
> following the same approach as `REL_2_STABLE`.
>
> 5. Define the upgrade and compatibility strategy
>
> Since Cloudberry 3.0 is based on PostgreSQL 16, we should explicitly
> document and test the upgrade path from the previous Cloudberry
> release, including:
>
> - Upgrade limitations and known issues
> - Upgrade documentation
> - Compatibility of existing extensions and tools
> - Support for Cloudberry 3.0 upgrades in tools such as `cbcopy`
>
> I would be happy to serve as the Release Manager for Cloudberry 3.0
> and coordinate the release planning, remaining development work, RC
> preparation, and communication with related projects.
>
> Please share your thoughts, concerns, and any additional release
> requirements.
>
> Best,
> Dianjin Wang
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> For additional commands, e-mail: dev-help@cloudberry.apache.org
>
>