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

[alexcrichton]

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

[alexcrichton]

Oh gah thought I accidentally closed it, then I realized it legit closed it, sorry for the noise...

[aturon]

@BurntSushi There are a couple approaches we might consider here:

• Introducing more cfg switches to make it easier to "polyfill" from older versions of Rust. For example, #[cfg(stable(duration))] or some such.
• Introducing some explicit version and/or feature dependency specification in Cargo.toml, and keying off this when resolving a dependency graph. There are a lot of fine details here, but @wycats has a rough design in mind.

I expect this will become a more pressing issue when we start to stabilize major language additions like specialization.

[BurntSushi]

Sounds good.

I've released 0.1.67 on crates.io with #209 (and the perf improvements from #205 :-)).

[DanielKeep]

@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 cargo update and just checking the code out for the first time as a new contributor or user.

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