Hacker News new | past | comments | ask | show | jobs | submit login

Hi. As I said in that page, I do know that cargo is working as designed, and that "0.4.1" is the same as "^0.4.1". My point is maybe a little more subtle, that cargo takes the newest allowed under the constraints, so given "^0.4.1", it has a choice between 0.4.1, 0.4.2, 0.4.3, 0.4.4, and 0.4.5, and it takes the last.

When you're adding a new direct dependency, taking the latest is almost certainly right. But when you're pulling in a new transitive dependency, I think taking the last is problematic: it seems much safer to me to take the one closest to what the author of that code tested with.

I'll elaborate more on this in a post tomorrow.

For what it's worth, I think I do understand what cargo is doing, and why, and I completely respect that approach. I just think this other approach might have some different properties worth exploring. As I've been working on this I've been using cargo as the gold standard, really. If the end of this all is that people say Go's package management is as nice as cargo, then I will be very very happy. A long way to go yet for sure.




I think your wording there is incorrect and very misleading, even if you do understand it. You say

> Cargo selects the latest version of a new dependency and its own new dependencies

but that's not true; it selects the "latest semver-compatible minor version", which is a pretty different thing. The way you've phrased it makes it seem like cargo just flat out selects the newest version period (which can cause breaking changes and a whole lot of pain).

So of course "people are frequently surprised", your actual statement is incorrect and misleading. "Blindly updating to new versions" is a completely different (and scary) proposition from "updating to semver compatible minor versions". The latter still has its issues (I think the maximally minimal approach that vgo is taking is a pretty neat solution to this and some other issues) but it's a much more contained set of issues.


> but that's not true; it selects the "latest semver-compatible minor version", which is a pretty different thing.

No, it's exactly the same thing. Russ already established that an incompatible module is not just a later version but, in fact, a totally different thing.


To be clear, I don't think you don't understand it; I'm afraid that the way that you've worded it means that others won't understand it.

I also very much don't think you should cargo cult! As munificient said above, this is a Hard Problem, and there are a lot of options. In some senses, I'm glad you're not just copying things, as well, that's how we all learn.


I think if you aren't going to simply "ignore versions", like we do in rebar3 and took from maven (we used cargo and maven/leiningen as the gold standards when working on rebar3) then taking the latest makes more sense. A patch version must be important enough to release instead of waiting for the next minor release, which I think says something about taking the latest.

But that is only if versions are used this way at all, I've found, at least in the Erlang world, the model of taking the first "version" found in the dep tree and locking to it to work well. In that case a patch version is not considered special anyway.


> I think taking the last is problematic: it seems much safer to me to take the one closest to what the author of that code tested with.

If someone doesn't respect semantic versioning the difference of one minor or few minor versions is irrelevant.

> For what it's worth, I think I do understand what cargo is doing, and why, and I completely respect that approach.

I think understanding SemVer would help a long way.


I get down voted but look at this https://go-review.googlesource.com/c/vgo/+/95700/4/vendor/cm...

hard coding v1 and v2 check, anyone who understands semvar would never make such mistake!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: