-
Notifications
You must be signed in to change notification settings - Fork 433
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
0.1.66 breaks semver #206
Comments
cc @Amanieu I'd love to avoid a semver bump. How hard would it be to make the |
This caused regex to require Rust 1.6, which really should require a semver bump since it will break existing code. For now, we'll stick with mempool and move to the faster thread_local version on the next semver bump (hopefully 1.0). Fixes #206
Just to clarify: I've worked around this for now by restricting the maximum version of Even if you bump the next release, keep in mind that Cargo will select 0.1.66 for existing code unless that code is modified. One possible resolution would be to release a 0.1.67 that resolves the issue, followed by a 0.2 (if you want to go down that road), and 0.1.66 would be yanked. That way, old code should continue to work. |
This is an interesting lesson to be learned. This means, for example, that once cc @rust-lang-nursery/libs @rust-lang/libs |
|
As a heads up, I tried compiling @BurntSushi You can use new features, you just have to gate them. Dependencies are a bigger pain, because I'm not aware of any way to control dependencies based on Rust version. |
@DanielKeep You might be on to something, And yeah, sure, conditional compilation will let us use new stuff. But that's a pain. :-) |
OK, I suspect removing the
|
Alternatively, I could have thread_local fall back to a |
Actually that won't work since I can't make the winapi dependency optional... |
@DanielKeep out of curiosity, what's the reason you'd like to stay compatible with 1.3? I haven't heard many reasons for moving back, so I'm quite interested in what's going on here :) In general I do not consider it a breaking change to require a newer Rust version so long as the newer version is "sufficiently old", so I wouldn't say that 1.0.0 of regex would never be able to bump the Rust version (it would just do so one a large-ish delay) |
Oh gah thought I accidentally closed it, then I realized it legit closed it, sorry for the noise... |
@BurntSushi There are a couple approaches we might consider here:
I expect this will become a more pressing issue when we start to stabilize major language additions like specialization. |
@alexcrichton Just to quickly address your question: because Cargo is ignorant of language version requirements, and because I said I would. If you're using 1.3, there's no way to stop Cargo from selecting a version of a dependency that you just can't use. I do consider that a breaking change, since it means that existing code can stop working, without modification. This applies to both I've worked on projects that were, for various reasons technical and practical, stuck on older compilers and libraries. As a result, I'm somewhat militant about sticking to compatibility promises, even the implicit ones. :) @BurntSushi Thanks for your work; again, I know this is a pain to deal with. <3 |
0.1.66 includes cdee1e7, which introduces a breaking change. Existing code that compiles under Rust 1.3.0-1.5.0 stops compiling due to the transitive dependency on
void
.The text was updated successfully, but these errors were encountered: