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
