Skip to content
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

Merged
merged 1 commit into from
Dec 6, 2017
Merged

bump lazy_static to 1 #33

merged 1 commit into from
Dec 6, 2017

Conversation

ignatenkobrain
Copy link

No description provided.

@nagisa
Copy link
Owner

nagisa commented Dec 4, 2017

I need to think a little bit more about implications of making a major version bump without any actual breaking changes.

@ignatenkobrain
Copy link
Author

I don't see any. Basically it is same as 0.2.11.

@Eijebong
Copy link

Eijebong commented Dec 5, 2017

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

@nagisa
Copy link
Owner

nagisa commented Dec 5, 2017

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 lazy_static it does't seem to be problematic, but it is not necessarily always a case.

@Eijebong
Copy link

Eijebong commented Dec 5, 2017

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

@nox
Copy link

nox commented Dec 6, 2017

@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.

@nagisa
Copy link
Owner

nagisa commented Dec 6, 2017

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?

@nagisa nagisa merged commit deac7da into nagisa:master Dec 6, 2017
@nagisa
Copy link
Owner

nagisa commented Dec 6, 2017

Thanks for the PR!

@nox
Copy link

nox commented Dec 6, 2017

Does it make it clear why I am wary of doing a breaking version upgrade for my dependencies?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants