In abstract, it doesn't take a huge amount of time and resources to do that. But, there are probably around a hundred higher-priority ideas achievable with the

In abstract, it doesn't take a huge amount of time and resources to do that. But, there are probably around a hundred higher-priority ideas achievable with the same resources which would take priority over this on the projects I'm working on right now. On projects I've worked on before, I think this would have made sense /technically/, given project priorities, but so did many other things which weren't done. It's a lot easier to make the case for resources for customer-facing features than for technical debt or infrastructure. So there's the political component too, which varies organization-by-organization. This is already done in a lot of projects with hardware. The Linux kernel will run on a thousand hardware and software configurations before integrating features. If I did this, I'd probably want at least three builds: * my pinned deployment versions (sometimes a release or two behind, sometimes bleeding-edge) * latest released version; and * HEAD If an upstream project is introducing a breaking change, I'd know immediately. That'd be super-helpful, probably both to me and to those projects. Come to think of it, the right way to do this might be to have three virtualenvs on my local machine, rather than just different targets in CI/CD....