0.1.66 breaks semver

[DanielKeep]

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.

[BurntSushi]

cc @Amanieu I'd love to avoid a semver bump. How hard would it be to make the thread_local crate work on Rust 1.3?

[DanielKeep]

Just to clarify: I've worked around this for now by restricting the maximum version of regex my crate will allow.

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.

[BurntSushi]

Yup, already ahead of you. :-) #208 should fix the issue. I'll yank 0.1.66 and push out a new release once #208 lands.

[BurntSushi]

This is an interesting lesson to be learned. This means, for example, that once regex moves to 1.0, it will never be able to use any new Rust features or standard library additions beyond what it could when it was released without a major version bump.

cc @rust-lang-nursery/libs @rust-lang/libs

[Amanieu]

thread_local 0.2.4 now supports Rust 1.3.

[DanielKeep]

As a heads up, I tried compiling thread_local 0.2.5 under Rust 1.3, and it failed due to its dependency on kernel32-sys which uses cyclic imports that confuse older compilers.

@BurntSushi You can use new features, you just have to gate them. scan-rules does this with a build script that enables various features based on the compiler version.

Dependencies are a bigger pain, because I'm not aware of any way to control dependencies based on Rust version.

[BurntSushi]

@DanielKeep You might be on to something, kernel32-sys is tested on Rust 1.4 for Windows.

And yeah, sure, conditional compilation will let us use new stuff. But that's a pain. :-)

[BurntSushi]

OK, I suspect removing the kernel32-sys dependency from thread_local is probably not realistic, since it's used for getting thread ids. So I guess that means we do one of:

1. We continue with the revert back to mempool.
2. We issue a semver bump to 0.2.

[Amanieu]

Alternatively, I could have thread_local fall back to a thread_local!-based thread id on older rustc versions (using build.rs to detect the rustc version).

[Amanieu]

Actually that won't work since I can't make the winapi dependency optional...