Skip to content
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

Closed
smesterheide opened this issue Mar 20, 2023 · 5 comments
Closed

Backwards compatibility #68

smesterheide opened this issue Mar 20, 2023 · 5 comments

Comments

@smesterheide
Copy link
Contributor

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.

  • Should the specification itself include all endpoints, schemas, etc. from previous versions (marked as deprecated)?
  • Should the API version be encoded in the URL path, eg. {server}/v1
  • How can an implementation advertise compatibility with multiple versions?
  • How does the discoverability endpoint /ocm-provider tie into that?
  • Do we maybe need a minor release first without any new features to facilitate backwards compatibility with new API versions?
@glpatcern
Copy link
Member

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).

@glpatcern
Copy link
Member

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)?
  • 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 (Add 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?

@smesterheide
Copy link
Contributor Author

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.

@glpatcern
Copy link
Member

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.

@glpatcern
Copy link
Member

Closed by #69

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants