> onSharedStorage = True > on_shared_storage = False This is a good example. I'm not sure it's worth breaking users _or_ introducing a new microversion for something like this. This is definitely what I would call a "purity" concern as opposed to "usability".
Things like the twenty different datetime formats we expose _do_ seem worth the change to me as it requires the client to parse a bunch of different formats depending on the situation. However, we could solve that with very little code by just exposing all the datetimes again in proper format: { "updated_at": "%(random_weirdo)s", "updated_at_iso": "%(isotime)s", } Doing the above is backwards compatible and doesn't create code organizations based on any sort of pasta metaphor. If we introduce a discoverable version tag so the client knows if they will be available, I think we're good. URL inconsistencies seem "not worth the trouble" and I tend to think that the "server" vs. "instance" distinction probably isn't either, but I guess I'm willing to consider it. Personally, I would rather do what we can/need in order to provide features in a compatible way, fix real functional issues (like the datetimes), and not ask users to port to a new API to clear up a bunch of CamelCase inconsistencies. Just MHO. --Dan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev