Status of Robot Framework versions / Robot Framework release cycle

[damies13]

It would be nice to have a page that shows the "supported" status of each Robot Framework version, something like this page for python

Status of Python versions / Python release cycle

I say "supported", knowing it's community supported but it might be useful to have some sort of guide as to when a Robot Framework version is too old and usage should be discouraged or users should be more strongly encouraged to move forward.

Background:
I was looking at my tests for RFSwarm, that are running on python 3.7, thinking should I drop support for that python version, went to that page and found it was EOL last year, which got me thinking what's the oldest supported Robot Framework version I need to also consider? at the moment my tests are just running on latest RF version, which by happy coincidence meant for the current release I'm working on I'm testing on RF7.0 and RF 6.1.1 but I was thinking I should test with more RF versions.

[kkotenko]

I agree on the main point of having a release schedule, but:

I'm testing on RF7.0 and RF 6.1.1 but I was thinking I should test with more RF versions.

What value do you see in that? As far as I am ware, RF 6.1.1 and 7.0 should be able to cover everything you can do with earlier versions, and there is no point re-implementing RF 6.1.1 tests for, say, 6.0.

[damies13]

I was more worried about testing with a 5.x and 4.x versions of RF, but if they are no longer supported versions it's easier to say there's no need to test with them.
When I started the rfswarm project RF 3.2 had yet to come out (still in RF 3.1.x), so at some point RF 3.2 worked with and the versions since worked with rfswarm, I believe they probably still do but I don't test them, but should I? If they're not supported then probably not.

[pekkaklarck]

We in general only support the latest release. For example, if you now encounter a bug, we'll try to fix it in RF 7.0.1. Once that release is out and we start RF 7.1 development, reported issues will be fixed in RF 7.1. We'd only consider creating RF 7.0.2 in very special cases. So far the only time we've backported a fix to an old release was with RF 4.1.3 and we did it because:

• RF 4.1.2 had an annoying backwards incompatible problem.
• RF 4.1.2 was supposed to be the last release supporting Python 2, Jython and IronPython.

Do you think we should explicitly explain this policy somewhere?

[damies13]

Yeah I think that would be helpful to be documented somewhere whether that's on the main site or in the user guide if that's easier.