...

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

Contributor 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.

Open 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