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 > >
