-
-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad release? Sled 0.15.3 [has evolved into a discussion on versioning] #236
Comments
@passcod works for me. are you on a mac? |
please post specific breakage or I can't debug this. |
Works for me too:
|
Yeah, on a Mac.
(other 4 errors are the same messages at other places) |
@passcod what version of rust are you using? |
as you can see, 0.15.3 contains public read_only field: https://docs.rs/pagecache/0.2.1/src/pagecache/config.rs.html#69 it builds fine and passes tests on osx on travis I'm not sure how you're building this, but the signs point to user error. Try |
Ah. sled 0.15.3 specifies pagecache 0.2 but actually depends on 0.2.1? |
Yeah, if I specify
it matches the version constraints (of sled) but fails to build. |
Not terribly broken and easily fixable. |
not broken at all. specifying |
We're... interpreting version specifiers differently? I suppose. |
I think that's the contract post-1.0 with semver, but I can see how it
might be beneficial in some cases to be more strict. Could you tell me how
you were building sled? If you were pulling it in as a dependency and it
failed to build because of this, it's something worth tightening up the
process around for sure.
…On Feb 11, 2018 04:39, "Félix Saparelli" ***@***.***> wrote:
We're... interpreting version specifiers differently? I suppose. 0.2 says
"I'm compatible with all 0.2.x, but fetch the latest on update/new".
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#236 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABb40A9YkBaJkYga-RaETdE8UH29_9Evks5tTmDigaJpZM4SAkGB>
.
|
Raw semver, yeah, but not how cargo does it:
And from what I can reconstruct, I used cargo upgrade. I pulled sled 0.15.2 first a few days ago, then cargo-upgrade yesterday saw there was an update and put it up to 0.15.3, and then I just did a normal |
I mean, the same thing would have happened if I'd manually updated the version in the Cargo.toml without doing a |
I also prefer specifying |
That's because requirements default to caret. You can specify other modes, e.g. |
The behavior of What would be ideal is including some command like |
There's a cargo issue for it! rust-lang/cargo#4100 |
@passcod Strictly speaking, caret as currently defined in Cargo document doesn't guarantee that you'll get the most recent version. It just allows to fetch more recent ones. |
Yes, that is what I'm saying. Requirements, not guarantees. Hence this issue. Reading back, my answer to you might have been based on a misreading of what you were saying, sorry if it didn't make sense because of that. |
Until we do get this, I think |
|
@passcod Err, yes. I mean, incrementing the minor versions to keep exactly what is required would be ideal. In my opinion, though, it's a large maintenance burden to keep every dependency at the "right" version, and the advantage is not worth it. |
Ah, I see what you mean. Maybe in the meantime do the inverse? Always However, for crates developed in the same repo, like sled and pagecache are here, is it too much to update the version reqs? Just for those crates, not other/external deps. |
Personally I would prefer a slightly incorrect version specification over forcing updated versions of dependency-dependencies. I've had a dependency of a dependency of a dependency break on my system in the past, and being able to downgrade it was useful. I would definitely support using It isn't like I'm making any decisions here anyways, but I only see downsides to using Is there a particular reason you've used If there is, then I'd be all for this! I've just not seen it yet, and having As for keeping sled/pagecache in sync: I don't have any strong opinions one way or the other. If @spacejam finds this necessary, it seems reasonable. |
They're do different things that have orthogonal uses. |
I'm reopening this because it seems like something that is generating some useful discussion, and I'm learning things from all of your comments! Thanks for going deeper on this issue! It is not very much work for me to specify patch versions in sled for pagecache, and I think it's the correct thing to do when relying on new functionality, as it will prevent confusion like in the original issue here. And I can still be lazy when adding a patch to address an internal pagecache issue, because in the majority of use cases of building this as a dependency for something else, it will usually get picked up. I'm going to keep this open for a few days in case there are more people who want to share their opinions, but for the time being I'm going to start specifying minimum patch numbers in sled for pagecache when relying on a new feature. |
Marking this as resolved, but if the strategy of always bumping patch versions when relying on new functionality (and maybe sometimes being lazy about it otherwise) is insufficient to handle a particular case for anyone, please feel free to open another issue! |
It doesn't build, and looks like 0.15.3 is only a version in the tyler_failpoint branch. Possibly revert?
The text was updated successfully, but these errors were encountered: