On Tue, Feb 16, 2016 at 8:34 AM, Andrew Laski <and...@lascii.com> wrote: ...
> It's easy enough to think that users will just read the docs and > carefully consider every version increment that they want to consume but > when they've been on version 2.7 for a while and a new thing comes out in > 2.35 that they want they need to fully digest the implications of all 27 > intervening versions purely through docs and with the understanding that > literally almost anything about the semantics can have changed. So while I > love the freedom that it provides to developers I think it would be useful > to have a small set of constraints in place that helps users. Of course all > of my ideas have been duds so far and perhaps that's because I'm imagining > future scenarios that won't come to pass or that we don't care about. But > something has me concerned and I can't quite get my finger on it. > Contrived example alert: API version 2.10 adds a pile of parameters to POST /foo/. API version 2.35 fixes a problem in GET /bar/details. As a client, I might need the 2.35 fix before I have finished implementing the big new feature in 2.10 (and intervening) changes. The clients will then use the GLOBAL_API_VERSION=2.7 as a default and use a local 2.35 version for the /bar requests. This may get fun to manage over time, but allows the client to opt-in to new API features without having to swallow the entire thing. It also increases the pressure to make sure the docs are up to snuff for each specific API bump. dt -- Dean Troyer dtro...@gmail.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
