All -

The discussion on jira:
https://issues.apache.org/jira/browse/HIVE-7010leads me to believe
that we will need to deal with multiple API versions
via component release versions - as Kevin has spoken of as well.

Templeton is removing the .../v1/queue APIs and adding a .../v1/job APIs.

The way that they seem to evolve APIs is to deprecate something for 2
releases and then remove them. Presumably the notice to prepare to migrate
is used as "backward compatibility" - which may make sense.

With the addition of service params in 0.4.0, we may be able to indicate
the version as a param and have the contributors load the appropriate
rewrite rules. Otherwise, we could also add an explicit version element to
the service definitions.

Either way, we will need to default the versions to the supported component
versions in 0.4.0 - since we don't have any explicit version mechanism yet.

Thoughts?

--larry

Reply via email to