[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-21012: ------------------------------------ To get value out of deploying JBT components' update sites to Nexus, a) component leads need to upversion their x.y.z+1 (3rd digit) for every milestone release, eg., in a task JIRA like JBIDE-20947 b) component leads need to ensure that every time they upversion and their Nexus URL changes, they submit a PR against jbosstools-build to change the URL in the parent pom. This will ensure all projects downstream use their correct latest bits c) releng & QE need tools to audit when a component lead forgets to do (a) and (b) d) releng & QE need tools to audit contents of JBT/JBDS update sites, since we will no longer be able to just visually inspect the list of features [1] to ensure they all have the same BUILD_ALIAS [1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars... ----- We could adopt a numerical convention that mimics Alpha/Beta/CR/Final nomenclature. For example... instead of having a project versioned with: * 4.3.0.Alpha1 * 4.3.0.Alpha2 * 4.3.0.Beta1 * 4.3.0.Beta2 * 4.3.0.CR1 * 4.3.0.Final/GA we might use * 4.3.011 (1 = Alpha, 11 = Alpha1) * 4.3.012 * 4.3.051 (5 = Beta, 51 = Beta1) * 4.3.052 * 4.3.091 (9 = CR/Final/GA) * 4.3.092 then for 4.3.1 maintenance... * 4.3.151 (51 = Beta1) * 4.3.152 (52 = Beta2) * 4.3.191 (91 = CR1) * 4.3.192 (92 = CR2, if needed) By using fully numeric BUILD_ALIAS values in the third digit instead of alphanumeric strings in the 4th, we could potentially use Nexus more easily. So, what if a component is already on 1.5.100? Well, we'd upversion it to 1.5.151 (Beta1). If it's already on 1.9.3, it'd be moved to 1.9.351. Only thing I need to verify w.r.t. this plan is if we can set a <version>1.5.1${BUILD_ALIAS}</version> with <BUILD_ALIAS>51</BUILD_ALIAS> and have maven not complain about the idea of nesting a variable in the version field. -- This message was sent by Atlassian JIRA (v6.4.11#64026)