[teiid-issues] [JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs

[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3462: --------------------------------------- So the full proposal would be along the lines of we will allow both semantic and the old revision based mechanism. You'd be allowed to use one or the other, but not both. For that we'll make the version integer optional in the vdb.xml - for both import and for the vdb itself vdb deployments with a name (or deployment name) of the pattern - name.v[semantic version] will be understood as versioned and we could support a qualifier in the version - SNAPSHOT, but I'm not sure if we want to go to that extent. If there is no semantic version specified, we'll effectively treat it as 0.0.0. In database metadata system functions for backwards compatibility we'll just report the base name as the vdb name. The semantic version would be reported in the system virtualdatabases table. For all api calls the vdb name would be the full name. For connection strings we'd then support: name - same as before latest connection type any. name.1 - would mean version 0.0.0 with revision 1 name.v1.1.1 - means exactly that version name.v1 - short-hand would be supported, so this would be the same as name.v1.0.0 New feature: name.v1. - means it must have a major version of 1 I do agree that this is a lot of work. You can get part of the way in the existing scheme by including the major version in the vdb name - foov1, foov2, which would mean that you could use the version field for micro releases - however this means that clients are dependent only on major versions and there would be no qualifier support. A hybrid approach would be to somehow let the current version field represent the micro version number. -- This message was sent by Atlassian JIRA (v6.4.11#64026)