GitHub user edespino added a comment to the discussion: [Proposal] Upgrade the
PostgreSQL version from 14 to 16
**Thanks for initiating this important proposal. I fully support the goal of
aligning Apache Cloudberry with upstream PostgreSQL enhancements. That said,
there are several foundational areas that need clarification and community
discussion to ensure the upgrade is successful, maintainable, and inclusive of
all stakeholders.**
---
### 🚩 Release Lifecycle Policy: Unclear
The proposal asserts:
> "Apache Cloudberry 2.0 will remain supported beyond PostgreSQL 14’s EOL."
> "Both 2.0 and 3.0 are planned for long-term support."
However, the project has **not yet published or discussed a formal release
lifetime policy**. This makes it difficult for users, downstream integrators,
and commercial adopters to plan around version stability and upgrade timelines.
Key open questions include:
* What does “long-term support” mean in practice?
* Will Apache Cloudberry versions follow PostgreSQL’s \~5-year support window?
* Will maintenance continue for EOL'd upstream kernels via backports or
security patches?
📌 **Recommendation:**
A **minimal versioning and support policy** should be drafted and published.
This can be done by **any contributor, committer, or PPMC member**, and does
not need to be authored by the original proposal writer. Even a placeholder
policy would help clarify expectations.
Here’s a suggested draft format to seed discussion:
<details>
<summary>📄 Example: Minimal Versioning and Support Policy</summary>
```markdown
## Apache Cloudberry Versioning and Support Policy (DRAFT)
Apache Cloudberry follows a major.minor.patch format:
- Major: Kernel upgrades or breaking changes (e.g., PG14 → PG16)
- Minor: Backward-compatible feature additions
- Patch: Bug and security fixes
| Version | PG Base | Status | Maintenance Target |
|---------|---------|----------|------------------------------|
| 2.0.x | PG14 | Active | Through at least 2027¹ |
| 3.0.x | PG16 | Planned | PG16 EOL + 1 year (tentative)|
¹ PG14 EOL is in 2026; Cloudberry 2.0 will continue receiving critical fixes
beyond that date.
Upgrades will follow standard PostgreSQL tooling (e.g., `pg_upgrade`) where
feasible. Changes to this policy will be proposed on the dev@ mailing list.
```
</details>
---
### 🔄 Upgrade Path for Users: Not Addressed
There is no mention of how users are expected to upgrade from Apache Cloudberry
2.0 (PG14) to 3.0 (PG16).
Key questions:
* Will in-place upgrades using `pg_upgrade` be supported?
* Will logical dump/restore be required?
* Are any major compatibility caveats expected (e.g., catalog changes,
extension rewrites)?
📌 **Recommendation:** Outline the expected upgrade path or link to a follow-up
issue/mailing list thread where this will be clarified.
---
### 🌿 Development Workflow and Branching: Needs Clarification
At the time of this proposal, Apache Cloudberry 2.0 has not yet been officially
released. As such:
* The `main` branch is currently tracking work for the 2.0 release.
* A `REL_2_STABLE` branch will be created when 2.0 is cut.
* The PG16 upgrade work is **expected to follow immediately on `main`**.
This raises an important question:
> **If PG16 work begins directly on `main`, and this work is long-running, how
> will that impact other contributors and feature development?**
> Will it effectively "hold `main` hostage" for months, making it difficult to
> keep it in a releasable state?
📌 **Recommendation:**
* Consider doing PG16 upgrade work in a **dedicated feature branch** (e.g.,
`pg16-integration`) to keep `main` clean and releasable.
* Allow post-2.0 fixes and small enhancements to continue on `main`.
* Establish a merge/rebase plan for when PG16 work is production-ready.
Keeping `main` stable supports CI, release planning, and encourages ongoing
community engagement outside the upgrade track.
---
### 🧪 Test Plan: Needs Clarification
While the proposal estimates \~3 months for regression fixes, it doesn’t
specify:
* Whether parallel testing against PG14 and PG16 will be done
* If test framework changes will be required
* What success criteria define a “complete” upgrade
📌 **Recommendation:** Expand the proposal to include:
* Testing scope across extensions and planner/executor behavior
* Integration with CI for continuous validation
* Clear thresholds for test suite compliance
---
### 🧩 Extension and Component Coordination: Missing
Apache Cloudberry includes many in-core components and bundled extensions
(e.g., PXF, gpfdist, PL languages, workload manager). A PostgreSQL upgrade will
almost certainly affect:
* Internal APIs
* Plan node compatibility
* System catalog behavior
📌 **Recommendation:**
* List all bundled extensions and components expected in 3.x.
* Assign or identify maintainers for each.
* Track PG16 compatibility status (via GitHub issues or a shared audit doc).
---
### 🌐 Downstream Ecosystem Impact: Private and Commercial Components
Apache Cloudberry is widely used in derivative commercial and private
deployments. Many such projects include **non-public extensions** or downstream
forks. These groups depend on **kernel compatibility and early visibility**.
📌 **Recommendation:**
* Share this PG16 upgrade plan early via:
* `dev@cloudberry.apache.org` mailing list
* GitHub Discussions or project roadmap
* Website changelogs or release notes
* Encourage downstream users to validate and share PG16 migration blockers.
---
### 📊 Tracking and Transparency: Suggested
As noted by @tuhaihe, the community would benefit from **centralized tracking**
of the PG16 upgrade effort.
📌 **Recommendation:**
Use a GitHub Project board, milestone, or Google Sheet to track:
* Merge status
* Extension compatibility
* Test suite progress
* Contributor assignments and review queues
This improves visibility, onboarding, and roadmap clarity.
---
### ✅ Summary of Actionable Follow-ups
| Area | Recommendation
|
| -------------------------- |
-------------------------------------------------------- |
| **Release Policy** | Draft and publish a minimal versioning & support
policy |
| **User Upgrade** | Define upgrade process from 2.0 → 3.0
|
| **Branching Strategy** | Avoid holding `main` hostage — use a PG16
feature branch |
| **Testing Plan** | Clarify testing scope and CI validation strategy
|
| **Extension Coordination** | Audit bundled components for PG16 compatibility
|
| **Downstream Impact** | Share the plan early with commercial/private
adopters |
| **Transparency** | Create shared tracking dashboard for upgrade
effort |
---
Thanks again for initiating this work. With these additional discussions and
supporting plans in place, the PG16 upgrade can move forward in a way that
benefits the entire Apache Cloudberry community — from committers to downstream
integrators.
Let me know if I can help turn any of these topics into individual GitHub
issues or mailing list threads.
GitHub link:
https://github.com/apache/cloudberry/discussions/1095#discussioncomment-13129188
----
This is an automatically sent email for dev@cloudberry.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@cloudberry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
For additional commands, e-mail: dev-h...@cloudberry.apache.org
