git-protocol: fix bad gitoxide release

[kim]

gitoxide's git-protocol released a breaking change from version 0.8.0
to 0.8.1. Satisfy the new API, require a lower bound of 0.8.1, and hope
for the best.

[kim]

@Byron it would be good to prevent these kinds of things in the future by giving known dependents a chance to test releases.

[Byron]

My apologies for this one, I don't even know how this could slip in and will assure it won't happen again. New tooling should facilitate that, even though it might have been responsible for the bad release (yanked) in the first place.

This, along with the collaboration PR feedback, is a clear wakeup call that will cause gitoxide to transition into the next stage of development. I think it's best summarized with going from the wild wild west to… something more civilized.

@Byron it would be good to prevent these kinds of things in the future by giving known dependents a chance to test releases.

I am thinking about adding a CI step to build radicle-link against the latest version of gitoxide, or integrate cargo-breaking into cargo-smart-release for additional protection, or both.

[kim]

TIL cargo-breaking. I wonder if it is able, or could be taught to catch intra-workspace versioning snafu: what also happened here was that cargo picked both 0.8.0 and 0.8.1 of git-protocol due to it being a direct dependency as well as a transitive one through git-transport. Or maybe it's just a bad choice of cargo to impose different constraints on the solver depending on the presence of absence of leading zeroes 👿

Thinking about it now, I believe the issue (breaking change is not labeled SemVer-breaking) is virtually impossible to catch until it is too late: the dependent project would either need to be built against git tags, or crates.io would need to support some kind of pre-release publishing. Maybe the way to go is to integrate cargo-breaking into gitoxide's CI, so versions need to be bumped right away (instead of when releasing)?

[Byron]

Or maybe it's just a bad choice of cargo to impose different constraints on the solver depending on the presence of absence of leading zeroes

To my mind cargo acted unsurprisingly, as opposed to what happens when these pesky 3.0.0.BETA-4 dev versions are used (they are usually always breaking but to Cargo they are like patch level - if these are not pinned in the consumer as well as in transitive dependencies you build will likely break once a new BETA-X is released).

However, when bumping minor releases in pre-release software I think cargo smart-release should also bump the consumer's minor version to avoid, say, git-object going to 0.5.0 from 0.4.0 and the consumer git-protocol only goes from 0.2.0 to 0.2.1. Consumers of git-protocol 0.2.0 will auto-upgrade and might end up with two incompatible git-object crates in their dependency tree which can trivially break their build.

Maybe the way to go is to integrate cargo-breaking into gitoxide's CI, so versions need to be bumped right away (instead of when releasing)?

I plan to make it a written guideline to do exactly that - when making a breaking change, also bump the version number accordingly, even if this means the version is bumped multiple times without publishing (leading to sparse releases on crates.io). That way, one will not miss it. That's the way I wanted to work but thus far I was lacking the tooling and the awareness.
cargo breaking could be used as additional failsafe, and I would like to look into it. With its limitations it's certainly not a thing to turn a CI red just yet.