Minimum cargo-insta version in `Cargo.toml`

[konstin]

We had cases in our team where we saw churn in PRs with inline snapshots because different team members were using different cargo-insta versions. Would it be possible to define a minimum cargo-insta version in Cargo.toml, that ensures that you aren't on a too old version?

[max-sixty]

I have very much tried to keep the snapshots backward & forward compatible. we have one miss with a ron format change

...though that should have been quite niche. Are there others?

I agree the "min version" be a viable solution if we're breaking compatibility, but it's much worse than avoiding breaking compatibility — how do folks know which min version they require? I think insta should pay the tax for this maintenance rather than users! We do have some tests for this, though by no means full coverage.

[konstin]

I'm mainly seeing @r###"/@r"/@" churn in our snapshots, as I understand there were superfluous annotations that aren't added anymore in recent version and now clippy also lints against.

[max-sixty]

does it fail with one version? or it's that the output has unrelated syntax changes when writing a new version of a snapshot?

[konstin]

There's no failure, this is about the noise that churn introduces in PRs.

[max-sixty]

right, but tbc, the snapshot only needs to change if there is a failure in the existing snapshot test?

though possible your snapshot results change quite often and this means there are often lots of unrelated syntax changes along with the snapshot changes? is that right?

[konstin]

Oh that's what you mean with failure, yes our test suite is mostly snapshots and many PRs update them. There's also some churn when someone e.g. changes a snapshot in one iteration, but undoes the change later, so only the string type change remains (e.g. " -> r" due to the older version).

I'd need to dig a bit deeper to make a reproducible example, but I had to cases in our team where we saw churn on PRs and that was fixed by the team member upgrading their cargo-insta version.

[max-sixty]

There's also some churn when someone e.g. changes a snapshot in one iteration, but undoes the change later, so only the string type change remains (e.g. " -> r" due to the older version).

yes, this makes sense. so they're compatible with both versions, but the versions will create different surrounding syntax

I'd need to dig a bit deeper to make a reproducible example

no need!

---

I think we're mostly done with the syntax changes, and I think the usability of this would be worse than it might seem at first So my inclination is to not add it. I'll leave it open to see whether there's more demand for it — is that reasonable?

[konstin]

As an example of the churn I mean: astral-sh/uv#18183. In the PR all the churn is forward, we're removing unnecessary annotations and blank lines, but with an older version, you could change those backwards to add unnecessary annotations.