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

Plans for version clause: Removal or API contract #684

Open
matthewfeickert opened this issue Dec 8, 2022 · 1 comment
Open

Plans for version clause: Removal or API contract #684

matthewfeickert opened this issue Dec 8, 2022 · 1 comment

Comments

@matthewfeickert
Copy link

matthewfeickert commented Dec 8, 2022

Hi @matthewfeickert, the version clause indicates basically the first REANA version where the example was developed for and successfully working on. We always test the full reana-demo-* test matrix before releasing later REANA versions, so the example has been working on 0.3, 0.4..., 0.9,etc.

Hence updating the version clause value to 0.9.0 shouldn't be really necessary -- and could actually be misleading, since some people could interpret it that this example is runnable only from REANA 0.9.0 onwards.

I would therefore propose to simply keep the original versions there.

Alternatively, since I agree that the version part may be confusion-prone, we could do one of the following:

  1. We could actually think of deleting the version information altogether. We do not take advantage of the version value when running the workflow on the server side, because we had not really introduced any breaking changes to reana.yaml so far since its inception. Hence all past reana.yaml files should be transparently supported on newer REANA clusters regardless of their version directive.
  2. Perhaps we may want to switch to using version: 1 value and consider it as a kind of "API contract" version for the YAML structure, similarly to docker compose yaml versioning. So, we would be basically telling that version: 1 of reana.yaml structure is supported on REANA 0.3, 0.4, ... 0.9,etc servers, and we would upgrade reana.yaml to version: 2 only when some future REANA 7.0 version would introduce breaking changes to reana.yaml. The whole version directive business might be clearer that way. WDYT? RFC CC @audrium @mdonadoni

Originally posted by @tiborsimko in reanahub/reana-demo-atlas-recast#42 (comment)

@matthewfeickert
Copy link
Author

matthewfeickert commented Dec 8, 2022

Thanks very much for your concise and helpful summary, @tiborsimko — you correctly identified my confusion. 👍

I'm personally in favor of the API contract sort of approach you described, as this makes it very explicit and is what I assumed the version clause meant originally.

I'm a user though, so I'd be very interested in hearing the views of the rest of the REANA dev team. I would assume that @lukasheinrich might have thoughts as well.

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

1 participant