> I thought micro versioning was so we could make backwards compatible changes. > If we make breaking changes we need to support the old and the new for > a little while.
Adding a new field alongside an old one in a structure that we return is not a breaking change to me, IMHO. We can clean up the datestamp formats that we return in that way: return both. For datestamps that the client passes (are there any of these?) we don't have to honor both and do conflict resolution if they disagree, we just honor the new one, clearly. > For return values: > * get new clients to send Accepts headers, to version the response > * this amounts to the "major" version > * for those request the new format, they get the new format > * for those getting the old format, they get the old format Yes, I think this is quite reasonable. I honestly think that in most cases we can avoid *ever* breaking the original return format without the code turning into a mess, and I think that's what we should shoot for. > We could port the V2 classes over to the V3 code, to get the code benefits. Yes. --Dan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
