-
Notifications
You must be signed in to change notification settings - Fork 901
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
Discussion: Start committing our lockfile #3085
Comments
I think Rust has good guidelines on why to or not to commit My opinion on this is that it's only useful for helping debug issues during development, but ultimately we should make sure that we always support the newest dependency versions as that is what users will get when they use Though I don't see a particular upside for this in Winit, I'm strongly against committing the |
We could use a lock file only for CI, but not actually publish it, there's nothing wrong with doing something like that. I also like that they talk about keeping msrv compat, yet we have Also, I think Cargo.lock is actually ignored from the deps. |
Yes, I'm fine with committing |
@kchibisov from #3486 (comment).
The default that has changed is that its not ignored in
I'm not against committing
Its still an issue if latest dependencies don't work, even if its not our fault. There might also be behavioral changes, again not our fault, that don't necessarily cause compile errors. I think its important that we advertise the right thing. As a library we can't publish the Updating |
This will report regardless upstream, because users run winit on CI as well, and I get more reports from winit not compiling with minimal version of dependencies than that new version broke something, in fact i never seen anyone breaking semver, but winit breaking min version happens quite often.
there's no point in updating unless you want to pull a new feature, that's the thing. And for breaking updates you already have to do that manually. |
We made a decision at today's meeting:
(I'm not gonna be doing this work myself, am feeling a little burnt out by this discussion, and ultimately I don't think it matters that much). |
In a recent blog post, the Cargo Team outlined some reasons why they've changed the default for
cargo new
to not exclude the lockfile from version control.I think
winit
should follow that direction, and start committing ourCargo.lock
.This would help greatly with our CI setup, both simplifying it in terms of caching, as well as making it break much less often due to changes in our dependencies.
On the other hand, perhaps it's a good thing that our CI breaks on changes in dependencies, it helps them discover unintended changes - hence why this is a discussion.
The text was updated successfully, but these errors were encountered: