[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3462: ------------------------------------- Let's take a step back, what are things we are trying to control with semantic versioning? I know caching (materialization, resultset, metadata, prepared plan) etc. But what is the real usecase for the user? why one is favoring existing way over the other? The JIRA lists as way to define "Type of Release" of the VDB, so that downstream client applications know that the VDB developer did or did not introduced the breaking changes inside the VDB metadata. IMO, there is NOTHING we can do to validate the fact that a given minor version of VDB did follow the rules of semantic versioning, thus I feel it does little advantage for teiid for taking such massive changes and breaking changes. The suggestions I have is, - why not we introduce a VDB level property for semantic version, then map this to the "vdb-version", so in cases where we check version number like JDBC connection, odbc connection, Teiid can provide alternative/additional ways to connect using the semantic version. Provide an Admin function to get one version from other. We can also think about re-working "connection type" based on semantic version. - use the current version number, but the customer/user requires a semantic version use a three digit number, where each digit signifies the major.minor.micro So, I favor to keep the version as is, and adopt/recommend to alternatives like above. -- This message was sent by Atlassian JIRA (v6.4.11#64026)