Seems to me they should still be reving their version number. For example
.../v1/queue
.../v2/job
Not that we have any say in the matter.
On 5/5/14 3:14 PM, larry mccay wrote:
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
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
