reanahub / reana

REANA: Reusable research data analysis platform
https://docs.reana.io
MIT License
127 stars 54 forks source link

Plans for version clause: Removal or API contract #684

Open matthewfeickert opened 1 year ago

matthewfeickert commented 1 year ago

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 https://github.com/reanahub/reana-demo-atlas-recast/pull/42#discussion_r1043099574_

matthewfeickert commented 1 year ago

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

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.