Howdy, I would agree that completing the Cherry Pick work makes sense.
JD - Founder - https://commandprompt.com/ - 24x7x365 Postgres since 1997 - Founder and Co-Chair - https://postgresconf.org/ - Founder - https://postgresql.us - United States PostgreSQL - Public speaker, published author, postgresql expert, and people believer. - Host - More than a refresh: A podcast about data and the people who wrangle it. On Tuesday, January 21st, 2025 at 6:34 PM, Dianjin Wang <wangdian...@gmail.com> wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org For additional commands, e-mail: dev-h...@cloudberry.apache.org
