Why Pin Dependency Versions?

[westy92]

I'm curious, why did you pin dependency versions instead of allowing updates to be used?

[dependencies]
toml_edit = "=0.20.2"
toml_datetime = "=0.6.3"

For example, toml_edit's latest version is 0.21.0, or 0.20.7 on the 0.20.x line. Likewise, 0.6.5 is the latest version of toml_datetime.

Upgrading proc-macro-crate just caused some of my dependencies to downgrade.

[bkchr]

Hey, because the new version of toml_edit and toml_datetime are requiring a newer minimal rustc version and this would require a major version bump of this crate.

[kayabaNerve]

Shouldn't the users who need a minimal rustc version vendor a lockfile which resolves this? I don't see why this crate should be so opinionated as it's effectively taking the role of the lockfile despite being a library, not a lockfile.

To be clear, I do get not updating to versions exclusive to new rustc versions. I don't get pinning to specific patch versions.

[bkchr]

There are some people who say that breaking MSRV requires a bump of the major version. Quite controversial topic, but I would follow this for now. I will hopefully in the short term write my own small toml parser to not require to pin the dependency.

[kayabaNerve]

I don't inherently disagree with the MSRV commentary. I was disagreeing that supporting a toml range which has options which breaks MSRV means proc-macro-crate is itself breaking MSRV, so long as the range has options which don't break MSRV. Of course, it's up to you, and I don't want to push the issue.

I do appreciate the planned migration which would remove the pin :)

[ilya-bobyr]

We use borsh which depends on proc-macro-crate.
After we upgrade our borsh to 1.2.1 our dependency graph is now broken.
We have another dependency on a crate that depends on toml version 0.8.8.
And toml 0.8.8 depends on toml_datetime 0.6.5.

A dependency on 0.6.5 actually means that >=0.6.5.
And an explicit =0.6.3 is incompatible with that.

cargo does not allow two versions of the same library that are different only in the patch version.
And so our project just does not compile with a newer borsh.

My understanding is that libraries should never use =X.Y version requirements.
It will create "breakage at a distance" that is impossible for your users to fix.
There is literally nothing we can do, except to fork this crate and remove the =X.Y version constraint, if we want a newer borsh.
We actually did it for two packages that are not maintained anymore.
As they block us from keeping our dependencies up to date.

I am pretty sure you did not want to block your users from moving to a newer borsh version :)

[ilya-bobyr]

Any chance #45 could be merged into the next release?