Plans for version clause: Removal or API contract

[matthewfeickert]

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