Spack changes quickly: if we want our spack/package.py to be up-to-date we
cannot rely on the same (up-to-date) version working well with older versions of
spack. In this PR, I remove the workflows that were testing the spack/package.py file for (older) releases of spack. We only keep testing the develop version of spack.
For that reason, I think we should only test here the current development version of spack: the purpose of the repository is to prepare changes to the devolep version of spack.
In the past, we have testied the latest Octopus release with the spack develop. I have now added that we also test Octopus develop on spack develop as a new workflow.
Spack changes quickly: if we want our spack/package.py to be up-to-date we cannot rely on the same (up-to-date) version working well with older versions of spack. In this PR, I remove the workflows that were testing the
spack/package.pyfile for (older) releases of spack. We only keep testing the develop version of spack.(Just ran into that problem at https://github.com/fangohr/octopus-in-spack/actions/runs/4366288303/jobs/7636090402#step:3:955 for example, where I used the
octopus/package.pyfile from upstream spack (i.e. the spack develop branch) and that cannot be used together with the latest release of spack.)For that reason, I think we should only test here the current development version of spack: the purpose of the repository is to prepare changes to the devolep version of spack.
In the past, we have testied the latest Octopus release with the spack develop. I have now added that we also test Octopus develop on spack develop as a new workflow.