These dependency versions are pinned precisely in the upstream Cargo.toml; if there's fixes from the new versions that are important to pick up, it would probably be a good idea to send a PR bumping the Cargo.{toml,lock} upstream.

Indeed. I guess they do this on purpose, to keep the version in sync. However, the build breaks without this. What do we do here?

Huh, that build error is really strange; for some reason cargo is insistent on updating probe-rs to a version that isn't what the Cargo.toml specifies, even though the versions specified aren't yanked or anything.

I think patching the lock file is reasonable for now, but bumping the versions evidently fixes things for users (us!) in practice, it'd be nice if the cargo-flash upstream could tag a new release with them.

cargo is insistent on updating probe-rs to a version that isn't what the Cargo.toml specifies

A few days ago I heard about this behavior to be intentional, cargo updates dependencies sometimes even if passed the --frozen argument and a Cargo.lock. The docs for --frozen state this (which implicitly explains the observation):

Either of these flags requires that the Cargo.lock file is up-to-date. If the lock file is missing, or it needs to be updated, Cargo will exit with an error.

Suggested change:

IIRC I once got the feedback to do the swap the other way round, as string interpolation is supposed to be more expensive than string concatenation. Is that wrong? I'm eager to know any rational to promote either the one or the other style.

I don't think it has much to do with speed, rather consistency and just the code being prettier. Reading the rev takes almost no time anyway, that doesn't really matter.

There's 9 instances of rev = "v" + version; being used throughout the codebase, versus the 1957 instances of rev = "v${version}";. For consistency's sake thats much better.

Whatever 😆

maybe also this? :D

A copy-pastable URL is probably better:

Hmmh, sure

said yes, didn't do it :P

Maybe now?