support some latest-1 versions in Jenkins testing
Current practice is to test the latest supported versions of stuff (compilers, libraries, etc.), for each branch on the slaves in Jenkins, and to express the coverage in the matrices in admin/builds so that Jenkins pipeline job can organize a matrix job to do the build and test given what is known to be installed on slaves.
At https://gerrit.gromacs.org/#/c/6919/ we had the suggestion to try to explicitly cover also a not-quite latest version to help try to avoid problems if some vendor might pick and keep a dependency that wasn't latest.
That would require the number of configurations and/or matrices to increase, and that is generally more work to set up and maintain build slaves. Workspaces do get full.
#1 Updated by Mark Abraham about 3 years ago
I think we should approach that by testing particular versions as we identify they exist. For example, we test the earliest supported compiler for both the earliest and latest supported CUDA version. If we would again have the situation where e.g. BG/Q compiler was a fork of a particular version of XLC, then we could test that version in Jenkins. This limits our additional work to situations that deliver known value. That is, the full range of this issue should be low priority / rejected until we have a volunteer to make it happen.