On 09/01/2012 02:11 AM, Clayton Coleman wrote:
hmm, to me to completely grock this: how do you achieve this beside the version in the accept-header? You'd check the api version that is reported in the responses and adapt your accept-header?
yes, we have pretty much the same requirements in the openshift-java-client. We expect to have to support different API versions since there'll be different servers available (local/internal installations, openshift.redhat.com, etc.)
yes, we also try to achieve this. We currently have a jenkins build setup that runs integration-tests against PROD, INT, STG etc. We plan to extend this test matrix by the different API versions.
so you plan to maintain a list of outdated, non-supported APIs and refuse to talk to them when the particular API version is EOL?
sure, completely agree on this basically. The openshift-java-client also simply ignores data that he's not aware of. The cases that are far more difficult to handle are the cases where property contents change semantically or properties even get removed. We're not completely sure how to support these 2 cases so far. I guess that we'll most likely maintain separate client objects for the different, non-compatible APIs. I hope that this will be enough. How are you supporting different non-compatible APIs in the CLI? Do you have distinct libraries for the different API versions?