Hi guys, I would like to bump this discussion again.
In Slack and other channels, a few community members have been asking about our first Apache release. Now our contributors are actively working on cherry-picking commits from the GP archived repo to Cloudberry[1]. IMO, it would be better to release a version after completing the cherry-pick work. Although this might take a bit longer, it will be worth the wait as it will enhance the project’s stability, improve compatibility with Greenplum, and make it easier for existing Greenplum users to migrate. FYR. Hope to have your ideas here. [1] https://lists.apache.org/thread/bf4n0p6jt8x2wnsmgwqwmqqboy4kq0st Best, Dianjin Wang On Wed, Dec 11, 2024 at 2:13 PM Dianjin Wang <wangdian...@gmail.com> wrote: > Hi team, > > It's great to see such active discussions! Just a friendly reminder that > our project name has been changed to Apache Cloudberry. So when referring > to the project, please feel free to use `Apache Cloudberry` or `Cloudberry` > going forward. Let's avoid using "Cloudberry Database" in the future. > > Thanks! > > Best, > Dianjin Wang > > > On Wed, Dec 11, 2024 at 12:15 PM Zhang Mingli <avamin...@apache.org> > wrote: > >> Hi All, >> >> I appreciate the ongoing discussion regarding the versioning strategy for >> Cloudberry Database. >> I wanted to share my perspective on why I strongly believe we should >> adopt semantic versioning (major.minor.patch) instead of the >> “year.release.patch” format seen in Clickhouse. >> >> 1. Alignment with Proven Standards: Cloudberry Database is built on the >> solid foundations of Postgres and Greenplum, both of which utilize semantic >> versioning. By following this established format, we align ourselves with >> best practices and reinforce our commitment to quality and consistency. >> >> 2. Avoiding Compatibility Issues: Our codebase includes numerous >> compatibility checks tied to the current versioning style. Switching to a >> different system could introduce a whirlwind of unnecessary troubles, not >> just for us but for every database and extension built upon Cloudberry. We >> must avoid the chaos that could arise from such a change. >> >> 3. Complications with Kernel Upgrades: As we prepare for our upgrade to >> the PostgreSQL kernel version (currently 14.4), changing our versioning >> style could complicate this process significantly. We would be juggling >> multiple versioning schemes, which could lead to a cascade of issues. >> Maintaining our current format will help streamline future upgrades. >> >> 4. Clarity in Communication: Semantic versioning provides clear >> communication about the nature of each release. Major changes indicate >> breaking changes, while minor updates signal new features without risk. >> This clarity is invaluable for our users, helping them navigate updates >> with confidence. >> >> 5. Predictability and Trust: Predictability is crucial for our users. >> When they know what to expect with each version, they can plan their >> upgrades without fear of unexpected issues. This predictability helps build >> trust within our community and demonstrates our commitment to best >> practices. >> >> 6. Future-Proofing Cloudberry: As we grow and evolve, semantic versioning >> offers a robust framework that can scale with us. It allows us to introduce >> new features, deprecate old ones, and maintain a clear upgrade path for our >> users. >> >> I believe that by adopting semantic versioning, we can solidify our >> project’s foundation and enhance the overall experience for our users. >> I look forward to hearing your thoughts. >> >> About frequency of our Cloudberry Database releases. >> I agree with the sentiment that we should not release very often. >> Stability is crucial for a database, and prioritizing a stable release >> schedule will ultimately benefit our users. >> >> >> Best regards, >> Zhang Mingli >> >> On 2024/12/09 06:26:13 Max Yang wrote: >> > Hi All, >> > >> > We need to consider when to release Cloudberry 2.0, and how often to >> > release it, which involves the following considerations: >> > The version number consists of three parts: < major >. < minor >. < >> patch >> > >, namely x.y.z. >> > >> > In the Greenplum release, the bump of major to major version means that >> > metadata and data are no longer compatible. Users need to upgrade or >> import >> > and export data that needs to be displayed. The general release >> frequency >> > is several years in Greenplum. >> > And bump of minor generally includes some feature releases, but it will >> not >> > cause data incompatibility. >> > Bump of patch is usually a bug fix. >> > >> > We need to consider release candence, especially for major release. >> After >> > the general version is released, there is a support lifecycle. >> Therefore, >> > when engineers submit code, they need to submit code to different >> branches >> > at the same time (such as 5X_STABLE and 6X_STABLE in Greenplum). If >> there >> > are too many versions released, users need to upgrade frequently, which >> is >> > another cost. This is also why we need to control the cadence of major >> > version releases. >> > In the previous roadmap discussion email thread, we mentioned a >> PostgreSQL >> > kernel upgrade in the near future. The planned upgrade to PostgreSQL >> 15.x >> > will bring a lot of metadata changes to the PostgreSQL kernel upgrade. >> In >> > Greenplum, major version release was also with the PostgreSQL kernel >> > upgrade. Is it a suitable time to wait until the PG 15.x or PG 16.x >> kernel >> > upgrade is stable? Welcome to discuss >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org >> For additional commands, e-mail: dev-h...@cloudberry.apache.org >> >>
