remove rtt-target from vl53l1-reg

[rursprung]

this dependency is not actually used in the crate but it's present in the released version of the crate. this leads to additional unnecessary dependencies in the consumers of this crate.

[rursprung]

just as a note: this crate is being pulled in through vl53l1x-uld:

$ cargo tree
[..]
└── vl53l1x-uld v2.0.0
    ├── cfg-if v1.0.0
    ├── embedded-hal v0.2.7 (*)
    └── vl53l1-reg v0.1.0
        ├── bitfield v0.13.2
        ├── embedded-hal v0.2.7 (*)
        └── rtt-target v0.2.2
            ├── cortex-m v0.6.7 (*)
            └── ufmt-write v0.1.0

and rtt-target v0.2.2 (which is not used at all) in turn pulls in cortex-m v0.6.7 which is outdated (current is v0.7.7). pruning this unnecessary dependency from the tree would be nice!

@mitchmindtree: since this dependency isn't used here and also isn't re-exported (= not part of the public API) it'd be great if this could then be released as a patch release (vl53l1-reg v0.1.1) so that it's semver-compatible and cargo can automatically pick it up (w/o requiring a new release of vl53l1x-uld). the release could/should probably also include an update of bitfield (v0.14 is out - my dependabot PR #4 should take care of that) and you might be interested in fixing other findings from your lib.rs dashboard before the release?

[mitchmindtree]

Thanks @rursprung! Would you be interested in helping maintain this crate? If so I can add you as an author here and on crates.io?

[mitchmindtree]

Also for future reference, this repo will auto-publish new versions of the crate provided that the version in the cargo toml hasn't yet been published, meaning PRs that bump the version only require pressing merge to publish.

[rursprung]

Thanks @rursprung! Would you be interested in helping maintain this crate? If so I can add you as an author here and on crates.io?

thank you, but no - i'm only using this sensor for one small project now and probably won't use it in the future (and might not have access to it then, either). but maybe @TomSievers might be interested since his driver crate is based on this one?

Also for future reference, this repo will auto-publish new versions of the crate provided that the version in the cargo toml hasn't yet been published, meaning PRs that bump the version only require pressing merge to publish.

oh, that's rather unusual (and seems to go against semver since the publishing can't know which part of the version number should be bumped?). i'm generally using manual releases and have started using cargo-release to automate some steps, which seems to work quite nicely.

just realised: the auto-publishing feature doesn't bump any version number, so it'll fail if this hasn't been done in the commit(s) being merged, as is e.g. the case here. so that way multiple PRs can be merged until one of them bumps the version number, leading to a new release.
will you create the PR for the version number if/when you're ready to publish it? (it's not super urgent for me).

[mitchmindtree]

thank you, but no - i'm only using this sensor for one small project

That's how I ended up creating this crate :)

will you create the PR for the version number if/when you're ready to publish it?

I'll likely just do it locally and push to master this time as it looks like there are some other warnings to address.