A lot of work has gone into the next release and I applaud all of it. Because this will be a major release, what is the anticipated upgrade path?
-Greg On Thu, Jan 23, 2025 at 1:34 PM Joshua D. Drake <em...@joshuadrake.me> wrote: > 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 > >
