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
