On Tue, 2010-04-13 at 09:15 +0100, Eoghan Glynn wrote:
1. Allow backward incompatible changes with a rev of the major
version, e.g.
on transitioning from 1.x to 2.x
2. Allow only backward compatible changes, which is the same as #1 except
never incrementing the major version
3. Allow only forward compatible changes, which effectively boils down to
adding a "void *" (e.g. an xsd:any in the XML case) to every type as the
future extension point
Seems that option #1 is considered a bit OTT in this case.
The second option would work fine if we were sure that purely additive
changes would always give sufficient flexibility, though of course it would
still be useful for clients to specify the least version they require in an
Accept header (with an implicit "or newer") so as to detect the case were a
more up-to-date client that depends on a newly added element/attribute is
invoking on an older server.
I was more thinking along the lines of:
- The initial release of the api has version=1.0 media types
- All changes in future releases must be backwards compatible
- We reserve the right to bump the major version of any individual
media type if we really need to make a backwards incompatible
change; in that event, clients will still be able negotiate the
original media type
That way an older client will always get any newer (backwards
compatible) media types and we only need to worry about supporting older
media types if we make a backwards incompatible change
Newer clients can detect new features by looking for the individual
features themselves. That also gives us the flexibility to e.g. backport
a feature to an older version without having to bump the media type
version
Cheers,
Mark.