Ed, I like the proposal to keep the semver meaning from the versions. It's a widely accepted practice to help customers figure out what to expect during the upgrade. For major version change, it requires a database data file upgrade (usually takes longer time to backup the database, doing the upgrade, preparing for the failure, and long rollback from the database backup, etc.), and usually takes a longer down time window.
Then for minor version change, like for bug fixes and minor features, and requires no change on the database files and no ABI change, and usually a much faster upgrade with just binary replacements. The rollbacks are also pretty fast too. With that in mind, then if we introduce a catalog change like Ed found in the main, the main will definitely bump to the next major release. Max, I fully support the idea of having a backward compatibility test, which can be as simple as taking the database from the previous major release. There are couple places we need to verify to ensure the backward compatibility: catalog, page layout, configure file, WAL format, and the ABI compatibility (which is pretty hard to check for completeness, but we should be able to do some sanity test) There are some ongoing projects like https://wiki.postgresql.org/wiki/GSoC_2025 for the PG ABI compliance checking, and something we may consider to borrow. To recap, I like the semver idea for the versioning to clearly indicates the incompatible changes, and I do understand the need from Max to coping with frequent catalog changes (the thing is, we can have many catalog changes, as long as we don't release between the major versions) Best, Shine On Mon, Aug 18, 2025 at 8:58 PM Max Yang <[email protected]> wrote: > Ed, thank you for bringing up this topic. > > We can keep the catalog of 2X_STABLE unchanged and defer all catalog > modifications to version 3.0, > which will be released together with the kernel upgrade to PG 16. > Doing so allows users to upgrade relatively easily over a fairly long > period of time. > The additional work introduced is that engineers need to submit code to two > branches (main and 2X_STABLE). > To ensure the catalog/data compatibility of 2X_STABLE, we must have > binary-compatible tests for protection, > but I don't think it's easy to conduct ABI compatibility tests. > > Best regards, Max Yang > > > On Fri, Aug 15, 2025 at 4:03 PM Ed Espino <[email protected]> wrote: > > > Dev, > > > > Out of curiosity, I set up a Cloudberry cluster using 2.0.0 RC3, then > > connected it to a build from main. I believe this revealed a catalog > > incompatibility. If that’s the case, we need to decide as a project how > to > > handle this from a versioning standpoint. > > > > My recommendation is that we adopt a Semantic Versioning (semver) > approach. > > In this case, we would move to version *3.0.0*, signaling that a catalog > > change (and therefore ABI/binary incompatibility) has occurred. This > makes > > it clear to users—just by seeing the major version number change—that > such > > incompatibilities exist. > > > > I’d like to get your thoughts on using semantic versioning or an > > alternative method to clearly indicate catalog changes. > > cbadmin@cdw:~/assembly-bom/parts/cloudberry/gpAux/gpdemo$ gpstart -a > > 20250815:00:32:55:066479 gpstart:cdw:cbadmin-[INFO]:-Starting gpstart > with > > args: -a > > 20250815:00:32:55:066479 gpstart:cdw:cbadmin-[INFO]:-Gathering > information > > and validating the environment... > > 20250815:00:32:55:066479 gpstart:cdw:cbadmin-[INFO]:-Cloudberry Binary > > Version: 'postgres (Apache Cloudberry) 2.1.0-devel+dev.2076.g36c > > 1e7a92c2 build dev' > > 20250815:00:32:55:066479 gpstart:cdw:cbadmin-[INFO]:-Cloudberry Catalog > > Version: '302506101' > > 20250815:00:32:55:066479 > gpstart:cdw:cbadmin-[INFO]:-COORDINATOR_DIRECTORY > > Catalog Version: '302502091' > > 20250815:00:32:55:066479 gpstart:cdw:cbadmin-[INFO]:-Catalog Version of > > coordinator directory incompatible with binaries > > 20250815:00:32:55:066479 gpstart:cdw:cbadmin-[ERROR]:-gpstart error: > > Catalog Versions are incompatible > > > > Regards, > > -=e > > > > -- > > Ed Espino > > Apache Cloudberry (Incubating) & MADlib > > >
