-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backwards compatibility #68
Comments
Let's discuss this as part of the call next Wednesday. I have a draft spec where I keep backwards compatibility whilst still supporting the new endpoints, and IMHO part of the questions are easily answered. But as usual the details are worth being discussed (e.g. how does the discoverability endpoint |
I'll try and answer the points above from the discussion we had yesterday, following the decision to go for version 1.1.0, but I have further questions:
|
Your draft spec does indeed address all the issues we are having with the current develop branch and the widely adopted v1 spec with respect no new features and maintaining backwards compatible on the spec level. Thank you very much! In addition we could make sure that when v1.1 drops it not only includes all the new endpoints but it also requires any implementation to support connections from OCM v1.0 using all the existing (and now somewhat deprecated) endpoints and schemas. In any of the next iterations when could then fill all the gaps how v1.0 is actually used by vendors (cf. protocol options, notifications endpoint) Regarding versioning I would say 1.x should remain backwards compatible with no breaking changes for existing v1.0 implementations. This way we could then lightly pave the way for a v2.0 that keeps all the good parts and removes the bad parts. |
I take from your comment that we should not really make At the same time, I believe that compatibility with the existing "out-of-standard/undocumented" v1.0 implementations should not be required for an implementation to be v1.1 compatible. In particular, we have in CERNBox a v1.1 implementation that does not understand the undocumented Surely, once other outstanding issues (including notifications, as you mentioned) are sorted out, I totally support that we can pave the way for a v2.0. |
Closed by #69 |
I am not sure if it was decided yet whether the next version (v2.0.0 as it stands now) will be backwards compatible with v1.0.0. As a reminder v1.0.0 is the only spec available with some degree of interoperability among vendors. As this is the stated goal of OCM we should maybe discuss this aspect before settling on the next version. As a starter maybe we can first agree on the notion of backwards compatibility.
{server}/v1
/ocm-provider
tie into that?The text was updated successfully, but these errors were encountered: