package org.apache.hadoop.gateway.deploy;
import org.apache.hadoop.gateway.topology.Service;
public interface ServiceDeploymentContributor2 extends ServiceDeploymentContributor {
  // The list of versions supported by this contributor.
  // Each element is formatted according to the Maven Enforcer plugin syntax.
  // Returning null indicates that all versions are supported.
  String[] getVersions();
}

<topology>
    <gateway>
    ...
    </gateway>
    ....
    <service>
        <role>HIVE</role>
        <url>http://localhost:10001/cliservice</url>
        <version>0.13.0</version>
    </service>
</topology>

Selection

1. In general the contributor declaring the latest explicit version support that includes the required version is selected.
2. In the case of a tie selection will continue with the next latest explicit version support
3. This will continue until a single contributor is selected.
4. If this is not possible an arbitrary selection will be made from the remaining candidates.

Questions

• Should ServiceDeploymentContributors be able to specify version ranges?
• How can a contributor that will likely work for every future version of a service declare that fact?
• How can a more contributor supporting a more specific version take precedence over a more generic?
• What happens during rolling upgrade where for example NameNodes of different versions are running?
• Should versions be specified as they are in Maven and probably the way the Enforcer Maven plugin as defined? 
  • http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
  • http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges