-
Notifications
You must be signed in to change notification settings - Fork 108
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
bump lazy_static to 1 #33
Conversation
I need to think a little bit more about implications of making a major version bump without any actual breaking changes. |
I don't see any. Basically it is same as 0.2.11. |
I updated it in every servo crate that had it (and some more) and didn't see anything fail because of that bump (no code change at all in those bumps) so I guess 0.2 is the same thing as 1.0 |
The point is that if I bump a major version of a dependency then dependents of libloading may or may not begin compiling in two distinct versions of lazy_static into the end binary. It is not entirely clear if bumping a major version of a dependency also needs a major version bump in the dependent crate. For |
It's not a problem for lazy_static It's a problem for things liks serde or heapsize as they have a public trait which is implemented everywhere and thus you can"t have two different versions |
@nagisa A major dependency bump is not a breaking change as long as this dependency doesn't appear in the public API of the crate. |
That is not always true either. As a counter-example, anything directly or indirectly using (even internally) non-standard linkage for its symbol(s) may break and thus not provide the necessary invariants in the public API anymore. libloading itself is an example of a crate which breaks when final binary has multiple versions of it linked in. Even without using any of the exotic features. See #32 specifically. I wouldn’t be surprised if there are many more cases like that out in the wild. If any of libloading’s dependencies relied on a similar invariant, bumping a major version of a dependency would necessitate a major version bump for libloading as well. Does it make it clear why I am wary of doing a breaking version upgrade for my dependencies? |
Thanks for the PR! |
I operate as if any non-standard linkage is part of the public API of everything that depends on it, so I think we were in agreement from the start. Fortunately there is no such thing in lazy_static. |
No description provided.