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
