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

Ensure Compatiblity with All TES Versions #60

Open
lbeckman314 opened this issue Feb 29, 2024 · 2 comments
Open

Ensure Compatiblity with All TES Versions #60

lbeckman314 opened this issue Feb 29, 2024 · 2 comments
Milestone

Comments

@lbeckman314
Copy link
Member

lbeckman314 commented Feb 29, 2024

Overview

Thanks to uniqueg for bringing up this point — prior to the next release we should ensure that py-tes continues to be able to support TES 1.0 servers in order to maintain backwards compatibility.

Steps for installing or configuring py-tes to use different versions should be included in the documentation.

Next Steps

Possible methods for ensuring support:

1. Extra code

Each TES version could be configured manually by the user, or perhaps automatically by py-tes by querying the server.

  • Pros: All code would be contained in the same codebase/branch
  • Cons: Additional dev time

2. Different branches

Each TES version would belong to a different branch in this repo.

  • Pros: Quick and easy for the short term
  • Cons: Requires additional work by the user

3. Another Way?...

@lbeckman314 lbeckman314 added this to the 1.0.0 milestone Feb 29, 2024
@uniqueg
Copy link
Collaborator

uniqueg commented Feb 29, 2024

Thanks @lbeckman314. I would just like to point out that another major con for option (2) is that you can't (easily) use py-tes in a context where you want to talk to multiple TES implementations - which may each implement a different TES version. For example, this could be a major obstacle to use py-tes when talking to a federated TES network.

On the other hand, another major con for solution (1) is that the additional dev time/code complexity/maintainability may potentially be increasing exponentially with the number of versions that need to be supported.

Perhaps a middle way would be to support all available versions for now (there aren't that many) and then deprecate old versions if things get out of hand in the future. For example, you could probably already deprecate (or even drop) support for any TES version below 1.0.0, because I don't think there are any implementations that aren't at least on TES 1.0.0.

The code to negotiate the version (simply fetch it from the /service-info endpoint) should be easy, and as differences between TES vesions are currently not too big, it is probably not a huge problem to support both 1.1.0 and 1.0.0.

BTW, note that currently there is code in py-tes that takes care of backwards comptaibility with 0.4.0 and earlier - where endpoints were located on different routes etc. In my opinion, you could probably dump that code and have things a little cleaner (and faster).

@vsmalladi
Copy link
Collaborator

I agree easy to support anything 1.0.0 and above. Likley will be fine until we have 2.0.0 as a breaking change.

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

No branches or pull requests

3 participants