On Tue, 2010-04-13 at 05:28 -0400, Itamar Heim wrote:
> From: rhevm-api-bounces(a)lists.fedorahosted.org
[mailto:rhevm-api-
> bounces(a)lists.fedorahosted.org] On Behalf Of Mark McLoughlin
...
> I guess there are two things I'm trying to avoid:
>
> - Having to support a client requesting 1.0 when the current version
> is 1.1 - if the changes between 1.0 and 1.1 are compatible, it
> really only adds a headache for us with no big benefit
[IH] I wouldn't set as a goal backward compatibility for all times.
Deprecating an API should be possible between major versions (or between
two major versions, giving users time to adjust).
It really depends on what exactly we're talking about deprecating. We've
already added a lot of room for flexibility to the design - e.g. the
client has to query the server for the list of available actions, so
clients should be able to cope well with us deprecating stuff like that
What kind of promises (e.g. we'll warn in the previous release about an
upcoming deprecation) we give for those kinds of cases is kind of
separate from the API design
But for other cases where we're changing some core semantics, this media
type version number will allow us to do that while still supporting old
clients. Frankly, I hope we never have to use it, but it's better to
design it in, just in case
> - Getting into a situation where we can't backport
features because
> we can't bump the version number - i.e. it's better to do feature
> negotiation on a per-feature basis rather than using a version
> number that identifies a set of features
[IH] this has a testing overhead though
I can think of several things you could mean by this, so could you
elaborate perhaps?
(e.g. testing overhead for client app developers, or QA overhead for
RHEV-M itself, or ...?)
Thanks,
Mark.