gix-testtools: Upgrade versions of gix crates

[joshtriplett]

This avoids duplicate dependencies in packages depending on both gix and gix-testtools.

[joshtriplett]

Would it be possible to get a gix-testtools release based on this?

Also, is there some process that could avoid having gix-testtools get out of sync?

[Byron]

Actually, I don't think I can do that as it will break the ability of cargo smart-release to perform a release of gitoxide. Publishes fail if the test-tools use dependencies in the workspace, and using a separate set of crate versions (that also have to be one major version in the past, ideally) was the only workaround I could find. (gix-testtools seems to be special as it's used as dev-dependency in crates that are also depend on it, it's a cycle.)

I'd also love to not have this special-case, but it will probably need more time than I can invest into cargo smart-release to find a proper fix for it - it's a complex tool that was rewritten once already, yet is totally under-tested. My hopes are that one day, cargo smart-release will only be used to set the crate versions update changelogs, while cargo publish can be used to publish everything in the right order - then it should be possible to remove this special case.

[Byron]

As this PR is blocked by technicalities and won't budge for that reason, I am closing it as the issue is likely to persist until cargo smart-release has been adapted to handle this kind of cyclic dependency correctly.

To re-state the problem:

• gix-* crates use gix-testtools = { path = "…" } as [dev-dependency].
• if gix-testtools also uses gix-* = { path = "…", version = "…" } declarations then the operation.
  • The problem probably isn't cargo publish, but cargo smart-release which incorrectly edits the manifests when adjusting crate versions.

The workaround for the problem as it's employed now is to let gix-testtools refer to gix-* crates which have been published before, and are at least a major version in the past. For some reason, it also doesn't work when it refers to crates.io releases of gix crates that are compatible with the respective workspace crates.

Now that I am thinking about it, another solution would be to completely remove all gix-* dependencies from gix-testtools. But after evaluating this option, I had to conclude that it's not possible as it relies on the signal-aware gix-tempfile implementation to assure its tempfiles are always removed.

In theory, gix-tempfile and gix-lock are stable, but in practice they have to get republished due to shortcomings in cargo smart-release - it currently simply can't keep major versions stable, an issue that will need to be fixed before stabilising additional crates.

Thus it's probably better to wait until cargo smart-release gets some additional development time.