Hi Ed, Agree that we have the first version 2.0 first, which can help us go through the entire process and run the release pipeline.
Generally speaking, the time for the first release will be longer than later. Thank you for volunteering as the release manager. Your many experiences will definitely help us, and the engineer will assist you in doing the relevant work. On Mon, Dec 9, 2024 at 3:01 PM Ed Espino <esp...@apache.org> wrote: > Hi Max, > > Thank you for raising these important points about release strategy. As > someone who has volunteered to be Release Manager for our initial Apache > releases, I'd like to share some thoughts: > > 1. I strongly agree with your semantic versioning proposal. You've > outlined it well - major.minor.patch (x.y.z) where major version changes > indicate breaking changes like metadata/data incompatibility, minor > versions for feature releases maintaining compatibility, and patch for > bug > fixes. Having this clear versioning scheme (semver.org) will help both > developers and users understand the impact of each release. > 2. Apache projects benefit from regular releases - they demonstrate > project health and provide opportunities to refine our community > processes. > While we need to be thoughtful about major version changes that impact > users, we shouldn't delay releases unnecessarily. > 3. Regarding branch maintenance (5X_STABLE, 6X_STABLE approach): This > was challenging even in a commercial setting with dedicated teams. We > should carefully consider our community's capacity to maintain multiple > long-term branches before committing to this model. > 4. The PostgreSQL major version upgrade is a significant undertaking. I > suggest we: > - Form a working group specifically for this > - Have community members volunteer to lead different aspects > - Create a detailed impact assessment > - Develop a testing strategy > - Document the process for future upgrades > 5. I believe we should proceed with planning a 2.0 release based on our > current catalog changes and compatibility requirements, independent of > the > PG 15.x/16.x upgrade timeline. The PG upgrade will naturally align with > a > major version bump when it happens, but shouldn't be a blocker for 2.0 > if > we have other breaking changes to address. > > As a next step, I propose working on our first Apache releases to establish > our processes. This experience will help us better plan and execute both > the 2.0 release and future PG version upgrades. > > I would like to formally volunteer as Release Manager for the initial > Apache Cloudberry (Incubating) releases. Having served as Release Manager > for several Apache projects over the years, I'm familiar with the process > and requirements. I'm ready to shepherd both the release process and this > versioning discussion, with the goal of working toward a 2.0 release (given > our likely incompatibilities) and potentially a 1.6.X release. While we > still have some process work to complete before we're ready for these > initial releases, I'm committed to helping drive this forward. > > Would others like to share their thoughts on this approach? > > Looking forward to the discussion, > -=e > > On Sun, Dec 8, 2024 at 10:26 PM Max Yang <maxyang...@gmail.com> 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 > > > > > -- > Ed Espino > Apache Cloudberry (incubating) & MADlib >
