Hi Andrey, Thanks for bringing up the ClickHouse versioning model - it's a fascinating alternative to consider. I particularly like how the year-based scheme instantly communicates version currency to users and the tiered functionality approach.
After considering both approaches, I still lean toward semantic versioning because: - It makes breaking changes immediately obvious through major version bumps - The database community widely understands and expects it - It aligns naturally with our catalog version and WAL file magic number changes - It provides clear rules for version increments that map well to database changes However, I think we could adapt some valuable ideas from the ClickHouse model: - Consider adding stable/LTS tags to certain releases - Adopt their tiered functionality concept to help users understand feature stability - Possibly include the year in our release notes/documentation for easy reference A critical point, regardless of which versioning scheme we choose: we need to actively encourage users to stay reasonably current with releases. While we understand that organizations often need time to upgrade, staying too far behind creates security risks and makes future upgrades more challenging. On Mon, Dec 9, 2024 at 1:41 AM Max Yang <maxyang...@gmail.com> wrote: > 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 > > > -- Ed Espino
