CI Python matrix too aggressive?
IAlibay opened this issue · comments
The more I think about it, the more I realise that the CI python matrix is too aggressive. It enforces NEP29 on downstream packages, who might want to actually be able to test with previous MDAnalysis & Python versions. For example, propkatraj has a very slow release cycle, it makes no sense for us to enforce NEP29 on it by means of CI.
One potential option here is to split the action in two - have a develop CI check that uses whatever Python versions MDA's develop uses, and then have a release (or whatever you want to call it) check that just uses pip or conda's resolver to pick up an appropriate version of MDA?
Yes, I was thinking about the same potential issue. Having a sliding window of tested Python versions might be annoying for some downstream developers.
have a develop CI check that uses whatever Python versions MDA's develop uses
Can we do this on the MDAKit register instead than on the cookie cutter? We could maybe ping (automatically) the maintainer of the kit mentioning that the package does not work to develop (and suggest potential actions, such as updating the code or pinning the MDA version).
I was thinking to add the minimum Python version on the cookie cutter configuration, so that we have to change it only in one place (partially addressing and we can update it so that new MDAKits work with the latest version of MDAnalysis.
We already do checks against develop and ping maintainers if things go wrong. That being said, having checks against develop in the repo itself is quite important, especially when you think about relying on a feature that might go away real soon.