Changing usage of git dependencies to include tags

[jake-g00dwin]

I've recently ran into issues where I ended up with multiple versions of the qingke and qingke-rt dependencies being pulled into a project I've been working on.

I think it may be a good idea to use github tags so that including the dependencies can be done by tag to help prevent these kind of issues.

something like:

# ...SNIP...

ch32-hal = {git = "https://github.com/ch32-rs/ch32-hal",
    tag = "0.2.1",
    features = [
        "ch32v203k8t6",
        "embassy",
        "rt",
        "time-driver-tim2",
    ],
    default-features = false,
}

# ...SNIP...

qingke-rt = "0.2.1"
qingke = "0.2.0"

Really I'm just purposing that we could have tags that would be tied to or match the crates.io version numbers.

I know it's possible to use the rev key but that seems a bit messy imho.

[jsprog]

I've recently ran into issues where I ended up with multiple versions of the qingke and qingke-rt dependencies being pulled into a project I've been working on.

My dependencies on qingke and qingke-rt are following the examples by setting the version to *

qingke = "*"
qingke-rt = { version = "*", features = [] }

I think it may be a good idea to use github tags so that including the dependencies can be done by tag to help prevent these kind of issues.
I know it's possible to use the rev key but that seems a bit messy imho.

Espressif already solved this by moving nearly all packages into a single repository https://github.com/esp-rs/esp-hal, thus patching different packages with the same rev would work.

Really I'm just purposing that we could have tags that would be tied to or match the crates.io version numbers.

Nothing is released at https://crates.io/crates/ch32-hal

[jake-g00dwin]

The issue I had wasn't with the two lines you're indicating it was with what automatically was pulled in and used by the ch32-hal crate when I went to run cargo check or cargo build(I think I had run cargo update at some point).

If you check out the dependency tree with cargo tree | less and search for qingke you'll find that it's possible for it to end up pulling in conflicting versions of the same crate.

user@os:~# cargo tree | grep qingke
│   ├── qingke v0.5.0
│   ├── qingke-rt v0.5.0
│   │   ├── qingke v0.5.0 (*)
│   │   └── qingke-rt-macros v0.5.0 (proc-macro)
├── qingke v0.2.0 (*)
├── qingke-rt v0.2.1 (*)

The above is mostly what it looked like when I checked it before.

And also yes I realize nothing is released as on the ch32-hal crates.io page.

That's not the case for the qingke and qingke-rt crate. They have the 0.5 version on the crates.io page but only the 0.3 tag on the repository. As you might imagine that can cause some headaches when needing to use another version but having to dig for commits instead.

qingke/tags
crates/qingke

I'm realizing that perhaps putting the discussion here may have been somewhat confusing as it involves both the ch32-rs repo and the qingke repo.

I do agree that putting everything into a single huge mono-repo could be a solution but I can also see how that could very easily make things harder to maintain and track issues for.

I can only assume that's why the main contributors have the project in it's current configuration.

Maintaining semantic versioning and tags for the existing repositories still seems like a reasonable solution to me but I could also be lacking in context or reasoning on what might be a higher priority.