I like the Clickhouse year version number thought but feel it doesn't communicate enough and could potentially mean a 2024 major release is where Cloudberry is at in 2025 which is not a message worth communicating.
Along the year number line of thought, consider PostgreSQL does major releases annually. Might we adopt the PostgreSQL major version? That equates to Cloudberry jumping to 14 next release. We can release minor and bug-fix versions at our own pace. My reasoning is the purpose of adoption. As a potential new adopter of Cloudberry, it may make it easier to comprehend compatibility & core PG features opposed to say "okay, Cloudberry is 2.x.y but how does it align with PostgreSQL features?" Catalog updates could make it tricky but believe it can be done. +1 on STABLE/LTS/RC tagging. -Greg On Mon, Dec 9, 2024 at 9:02 AM Antonio Petrole <apetr...@authenticdata.io> wrote: > Lots of great thoughts in this thread. Just want to share the sentiment as > someone who did professional services for Greenplum for almost a decade > that something like pg_upgrade would be really *really *great to have to > perform whatever conversions need to happen for major upgrades with the > user data as opposed to offloading/reloading or migrating the data. There's > a few different ways to do the latter and none of them are particularly fun > especially with large systems. > > And just my 2 cents as far as release cycles, I'd much rather have less > frequent releases that are more stable as opposed to more frequent releases > that are less stable. My experience tells me most companies and users will > not be planning to perform upgrades many times throughout the year, > especially on mission critical systems. I'd take stability and thoroughly > implemented features > instability and MVP's (or maybe minimum viable > features?) any day of the week. With that being said I agree with Ed that > not letting users get super far behind is also super important, there's a > balance to strike here for sure. > > On Mon, Dec 9, 2024 at 8:41 AM Roman Shaposhnik <ro...@shaposhnik.org> > wrote: > > > On Mon, Dec 9, 2024 at 3:27 AM Ed Espino <eesp...@gmail.com> wrote: > > > > > > 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. > > > > Just as a matter of convention, ASF projects mostly use semantic > > versioning. > > > > Other than that -- I personally like the other versioning scheme quite > > a lot -- it just is unusual around ASF (and more importantly its > > downstream consumers). > > > > Thanks, > > Roman. > > > > > > > > > > > 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 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org > > For additional commands, e-mail: dev-h...@cloudberry.apache.org > > > > >
