git-url: possible breaking change in public API surface between 0.7.0 and 0.7.3

[jokeyrhyme]

Duplicates

• I have searched the existing issues

Current behavior 😯

Howdie, thanks so much for sharing this project, it has been very useful for me <3

I wanted to ask about the version scheme in use for git-url, in particular: is it SemVer or some other scheme?

I have git-url = "0.7" in my Cargo.toml, and recently noticed that my builds started getting compiler errors, which seem to have started with the release of git-url 0.7.3

It seems that, among other changes, the new git-url version changed the function signature of git_url::parse() so that it no longer takes [u8], which I have been able to accommodate now in my project: https://gitlab.com/jokeyrhyme/tuning/-/merge_requests/26/diffs

It looks like this is the commit in question: f6506e0

Expected behavior 🤔

I suppose, if this were within a SemVer scheme, then bumping the version number of git-url to 0.8.0 might be an option

But, I'm a little rusty on pre-1.0 behaviour for version numbers :) I thought it was 0.MAJOR.MINOR , but 0.anything could also just not have the same API stability indication as 1.0 , so who know? :) 🤷

Again, thanks so much, I especially love the "serde1" feature flag for git-url, it's all terrific :) Thanks!

Steps to reproduce 🕹

1. use git_url::parse() in git-url 0.7.0 without compiler errors
2. update to git-url 0.7.3
3. see new compiler errors: expected struct BStr, found slice [u8]

[Byron]

Howdie, thanks so much for sharing this project, it has been very useful for me <3

Thanks for the kind words!

Apologies for the hassle. gitoxide crates use semantic versioning as does the entire Rust ecosystem (even though cargo does interpret semver in ways that make it more prone to breakage), and the reason for the breakage is me not leaving a commit message that would indicate this actually unclear. The commit message of the breaking commit is "change!: Use &BStr as input instead of [u8] (#450)" which would cause cargo smart-release to do a minor version bump automatically. I don't know why that didn't happen but will watch out in the future.

I have yanked v0.7.2 and v0.7.3, and have released v0.8.0 as one would have expected. Yanking the versions in question breaks the installation of gitoxide from crates.io, so I will have to choose the lesser evil and leave the crate as is.

After taking a look at the changelog it becomes clear that the commit message was correctly understood as breaking change, yet the newly created versions don't bump the minor version, just the patch level. This seems to have happened multiple times already at least in the git-url crate. I will definitely watch this next time I create a release, it appears cargo smart-release isn't bumping versions correctly even though it's supposed to be able to do exactly this (e.g. a plumbing crate has breaking changes, and releasing a down-stream crate make minor bumps in said plumbing crates and propagates this breaking change bump downstream).

I hope it doesn't happen again and hope I will be able to detect such issue in future and fix the bug, before such breakage happens again.

I am closing the issue as I am unable to fix it without breaking what's currently released.

[jokeyrhyme]

No worries, thanks again!