This is an attempt to sketch out the admin and developer visible changes that could be used to support version specific contributors.  This type of mechanism is required for two reasons:

1. Knox should prevent attempts to use REST APIs that do not exist in older versions of services.
2. Not all services maintain strict backward compatibility between versions and as such required different Knox behavior per version.

Below is a sample of how the ServiceDeploymentContributor contract could be enhanced to declare support for particular versions.

...

<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