Cargo-edit: API stability when used as a library?

[tarcieri]

Hello, I recently merged a PR to cargo audit to add a cargo audit --fix feature, ala npm audit fix, which uses cargo-edit-as-a-library to perform the upgrades:

https://github.com/RustSec/cargo-audit/issues/23

In doing so, I did pin very specifically to = 0.4.1 to avoid any breakages (specifically I'd like to align around git2 versions - see #341), but was curious if it might be possible to have a looser version requirement.

It looks like locking to a specific version was a good idea, because it seems we're already incompatible with cargo-edit v0.4.2:

https://github.com/RustSec/cargo-audit/pull/168/files#diff-c196526203005d3b71665eeedc3fec4c

Specifically, for LocalManifest::upgrade (which we use here):

this function takes 3 parameters but 2 parameters were supplied

Any thoughts on placing at least parts of the API under Cargo's take on 0.x semver, and making changes like this a minor version bump? (e.g. 0.4 -> 0.5)

[ordian]

@tarcieri thanks for the report! I think we should follow semver for the (whole) library, as it doesn't cost us an arm and a leg to bump the minor version in case of a breaking change. @killercup, wdyt?

[ordian]

(we've had a similar discussion in https://github.com/killercup/cargo-edit/pull/332#issuecomment-522227192)

[killercup]

Yep, agreed. I totally forget that this is not just a CLI, sorry! Feel free
to bump to 0.5 and yank 0.4.2!

On Fri, 6 Dec 2019, 17:50 Andronik Ordian, [e-mail] wrote:

(we've had a similar discussion in #332 (comment)
https://github.com/killercup/cargo-edit/pull/332#issuecomment-522227192)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/killercup/cargo-edit/issues/366?email_source=notifications&email_token=AAAE4X6U5UWEW44Q6HOLSR3QXJ7FZA5CNFSM4JW4NEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGEV2NI#issuecomment-562650421,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAE4XZPSTVKFLWK6FTVPCTQXJ7FZANCNFSM4JW4NELQ
.

[tarcieri]

Awesome, thanks!

[tarcieri]

Also, if it's not too much trouble, it'd be great if you could do a minor version bump whenever you update git2.

We're looking at using its vendored-openssl feature, and it'd be nice to be able to ensure feature unification for the same version. Otherwise it's one of our most painful dependencies due to the external library linkage so it's super swell not to have to help people debug two different semver incompatible versions.