Backwards compatibility about ocm-api HOT 5 CLOSED

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 /ocm-provider tie into all this).

from ocm-api.

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:

• Should the specification itself include all endpoints, schemas, etc. from previous versions (marked as deprecated)?
  • Yes. There's a single field marked as deprecated in #69
• Should the API version be encoded in the URL path, eg. {server}/v1?
  • I don't think this is worth it at this point.
• How can an implementation advertise compatibility with multiple versions? How does the discoverability endpoint /ocm-provider tie into that?
  • The discovery endpoint (#59) provides the supported protocols. Can we assume that IF the list of supported protocols includes more than webdav, THEN the implementation must be v1.1.0 capable? I think yes, though this was not explicitly stated at the meeting. Then, whether a v1.1-capable implementation is compatible with a v1.0 implementation: what about adding this in the discovery endpoint as an extra capability of some form?

from ocm-api.

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

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.

from ocm-api.

I take from your comment that we should not really make compatibility with v1.x as a capability, but rather assume it as required across any v1.x.

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 options, and while we may implement them after they get fully documented / reverse-engineered, this process will take time (this is actually part of the scope of the NGI grant), and IMHO that should not block the implementation of v1.1 by any EFSS.

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.

from ocm-api.

Closed by #69

from ocm-api.