reana
reana copied to clipboard
Plans for version clause: Removal or API contract
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 fullreana-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:
- 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 pastreana.yaml
files should be transparently supported on newer REANA clusters regardless of theirversion
directive.- 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 thatversion: 1
ofreana.yaml
structure is supported on REANA 0.3, 0.4, ... 0.9,etc servers, and we would upgradereana.yaml
toversion: 2
only when some future REANA 7.0 version would introduce breaking changes toreana.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