Run CI tests for all versions of rust-gpu that we support

[tombh]

We currently only test the latest supported version of rust-gpu, or at least the version that is pinned in the Cargo.lock file of shader-crate-template. This meant that a regression wasn't caught in #34 (see #34 (comment) for details).

I propose that we also test a version of shader-crate-template that uses the pre-cargo-cpu version of rust-gpu/spirv-builder, namely the v0.9.0 tag. And that, in the future, when more changes are made to the spirv-builder API, we test those versions as well.

I think the way to do it is to add the new test to the ubuntu-latest Workflow matrix, that way we're not doubling Github Action minutes and we're still getting test parallelism, so no build time increases. Let's hope there aren't significant differences in the spirv-builder changes between OS's, so that it's enough just to test on Linux.

[schell]

I'm in favor of this, though I don't think we need to worry about github minutes just yet. The main priority is saving us developer time.

[tombh]

Great, I've almost got this done. But there's a topic I'd like to bring up to see what you think. Basically, how many historical versions should we support?

Let me give you 2 notable data points to contextualise:

1. In order for spirv-builder-cli to support rust-gpu == 0.9.0 we need to pin to clap = "=4.4.8", because versions after that require rust >= 1.74, which conflicts with the nightly-2023-09-30 toolchain Rust version of rust-gpu == 0.9.0. This isn't a big deal, mainly because current clap is at 4.5.26, so we're not missing out on much. But also because we can always split clap into 2 separate feature-gated versions (as we do with spirv-builder). The only thing is though, is that it starts to get a bit cumbersome handling all these divergences for each version of rust-gpu. What if splitting some dependency version also means one day maintaining 2 refactors of the spirv-builder-cli crate?
2. In working on this parent issue here, I found a bug where changing an existing spirv-std version in a shader crate caused an error. It's good that we are currently aiming to support old rust-gpu versions, because all users should in theory be able to benefit from this fix just by updating cargo-gpu. In other words, an alternative approach to "supporting" older versions could be to just point users to older versions of cargo-gpu. But that has the downside of missing out on our up to date fixes.

My feeling is that we should aim to support as many previous rust-gpu versions as reasonably possible. Therefore whatever is straightforward. Which means we should also have a deprecation policy in place that supports culling cumbersome code.

More concretely, if we can say aim to support versions up to 2 years old, then that'd be great.

[schell]

if we can say aim to support versions up to 2 years old, then that'd be great

I think this would be great, and given the release cadence of rust-gpu is quite slow, that may mean only supporting two versions at any one time.

I'm wary of committing to an arbitrary number, though, and would rather take it on a step-by-step basis. I don't mind dropping support for an older version if that version takes lots of maintenance, because we simply don't have the resources.

2 years back roughly means 2 versions back (one at the current rate). But we also may get lucky and future versions won't take that much wrangling. We'll see 🤷 .

[tombh]

Great, let's do that then. With #41 we prove that we support 0.8.0, which is 18 months ago. We'd need to go back to 0.5.0 to get a full 2 years compatibility. So let's find the balance and say that 0.8.0 is good for the moment.

[schell]

Well I think it's fine to start with 0.10! We don't need 2 years compatibility from right now - but since it seems like you've already got 0.9 and 0.8 that's great, just don't go too far!