> We may need to differentiate between breaking the API and breaking > corner-case behavior.
Totally agreed. > In one case you force everyone in the ecosystem to > adapt (the libraries, the end user code). In the other you only > (potentially) affect those that were not following the API correctly. The problem is that the API spec is too loose right now, which is definitely a problem. However, I think I'd much rather tighten things down and deal with the potential fallout of someone's client breaking and saying "oh, I thought 'red' was a valid uuid" than whole rewrites. > We could make a V3 that doesn't break the API, only breaks behavior in > error cases due to its stronger input validation. A V3 that shouldn't > break code that was following the API, nor require heavy library > changes. It's still a major API bump because behavior may change and > some end users will be screwed in the process, but damage is more > limited, so V2 could go away after a shorter deprecation period. What's the difference between saying "/v2 will return a 404 after K" and saying "If your client doesn't declare support for revision 2 of these calls" we'll return a 405, 406, 410, etc? Actually, 412 seems to be exactly this case. --Dan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
