As of #8928 we test lakeFSFS with 50 versions of lakeFS. That's a bit much:
Not all lakeFS versions are there.
This is an integration test, so necessarily flaky. Indeed we already have occasional flakes. Every version we add increases the probability of flaking out - and this is superlinear, because adding load of any kind makes flakes more likely.
It adds little value. For a patch release in particular there should be no difference.
I would like to codify a policy for these tests:
Test nothing before 1.x (so remove 0.113.0, which AFAIR is 1.0.0 by its pre-release name).
Test only the latest patch version of each minor release (#8308).
@treeverse/product : declare a support window for lakeFS vs. lakeFSFS. During that window we might add patch releases, but lakeFSFS would continue to work.
Version pairs outside of the window would be supported just like any other software using the lakeFS API: if a lakeFS release breaks a version, we remain committed to fixing it.
I would be happy to declare some minor versions of lakeFS as "LTS" and commit to an X-month window of support. I suggest X=12.
Commit to a Y-month window of support for non-LTS minor versions, Y << X. I suggest Y=3.
As of #8928 we test lakeFSFS with 50 versions of lakeFS. That's a bit much:
I would like to codify a policy for these tests: