Python version conflict during a version upgrade

[jl-wynen]

When dropping support for a Python version, the 'Nightly tests at latest release' workflow is broken until a new release is made. (If it uses Scipp)

As an example:

1. Release package with, e.g., Python 3.9.
2. Set minimum to 3.10.
3. Update dependencies.
   • This will start using the py310 wheel of scipp.
4. Run nightly_at_release.yml.
   • This calls test.yml with tox-env: nightly and python-version: 3.10.
   • test.yml checks out the last release tag, installs Python 3.10 and runs tox -e nightly.
   • Tox installs dependencies from requirements/nightly.txt as it was at the release. I.e., it tries to install the py39 wheel for Scipp and fail.

We could mitigate this by requiring to make a release whenever we change the minimum Python version. But those releases are not necessarily meaningful.

I don't see a simple way around this. We might have to pull requirements/nightly.txt from main instead of a release tag. But that would probably cause problems as well.

[MridulS]

We could mitigate this by requiring to make a release whenever we change the minimum Python version. But those releases are not necessarily meaningful.

I think it's perfectly fine to make releases whenever the min python version is bumped. We don't need the releases to be packed with a lot of new stuff.