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
