Historically we have not tracked main because there have been periods where changes broke builds for a while. I'm wondering whether we want to allow main to fail, or whether that's no longer necessary because the Django project is pretty mature and we're not making changes as rapidly on Haystack either.

From my perspective; Github CI is kinda wonky when it comes to allowing things to fail, it wont be obvious that it is failing, and it will be a "out of sight, out of mind", and that is kinda scary.

My position is that we should test supported versions of Python (5 versions) times Django (3 versions) but not unsupported versions. We should not encourage users to run production infrastructure on unsupported software.

@cclauss so you're against running on CI, but not locally? Am i understanding you correctly?

PS. This is more of a "heads up", this is what is going to break in 6m-1y time, but you're the maintainers. Up to you.

We should always run 5 Py * 3 Dj on CI for all PRs and code changes.

We should always run 5 Py * 3 Dj on CI for all PRs and code changes.

so, you want to remove main.

what do you think about:

This is more of a "heads up", this is what is going to break in 6m-1y time

as in, sooner or later you need to maintain this, this way it gives you a heads up instead of a bomb at your doorstep that there is an incompatibility.

@cclauss thoughts ?

@cclauss I guess we have different definitions of

unsupported versions

or

unsupported software.

This is not versions that have been dropped, but instead are in active development and will be valid version in a not too far along future. This allows you to see what is coming down the pipeline before the actual release causes you alarm. What can happen here is to have this version not be [required] and if it fails is fine, you can still merge the PR (all this is configured in the github settings)