bump encoding_rs to 0.6

[ignatenkobrain]

No description provided.

[ignatenkobrain]

Looks like encoding_rs is not compatible with rust 1.12.... Not sure what you would like to do about that.

[BurntSushi]

Right. Could you:

1. Bump 1.12.0 in .travis.yml to 1.16.0?
2. Bumping just the Cargo.toml isn't sufficient. You'll also want to update Cargo.lock. You can do that by running cargo update -p encoding_rs.

Let's hope encoding_rs compiles on 1.16.0, but unfortunately, encoding_rs's CI doesn't seem to test on a specific Rust version. I'll file an issue.

[BurntSushi]

issue filed: hsivonen/encoding_rs#18 (comment)

[BurntSushi]

@ignatenkobrain We should probably have a discussion at some point regarding how we'll deal with these bumps going forward. This happened to be timed pretty well, since I've been wanting to bump the minimum Rust version for ripgrep for a while now. But I don't think I'll always be so accommodating? For example, when the time comes for ripgrep 1.0 to be released, it's not clear to me whether that means "ripgrep 1.x will forever work on Rust 1.y, where Rust 1.y is the minimum Rust version supported at the time ripgrep 1.x was released." If I choose that policy, then it seems like ripgrep will gets its major version bump at least somewhat semi-frequently. But what if I didn't want to bump the major version that frequently and instead stuck with Rust 1.y? Well, invariably, that would mean that I won't be able to update some of my dependencies. How much of a problem will that be for you? And more broadly, what are your thoughts on this type of policy?

[ignatenkobrain]

@BurntSushi Speaking on behalf of Fedora Rust SIG:

1. We are going to follow latest stable releases of rust for all version of Fedora.
2. We prefer to have only one version of crate (we can have multiple versions at the same time) and that should be latest one.
3. Because of 2, we bump version of dependencies so it will use latest version and write patch if it is not building. For non-trivial cases where we can't port ourselves (time or lazyness) we create compat package with old crate which means that it also needs some patching for its dependencies to use latest version and so on. So far in repo we have ripgrep, rustfmt, rustfilt tools and only one compatibility package is there (toml-0.2, because there were a lot of changes to 0.3 and I was not able to port rustfmt myself).

To summarize: We don't care about minimal rust version, it should be just some stable version. We would prefer if upstream will use latest-shiny version of crates so we will not do patching here and there.

I think it definitely makes sense to support some old compilers, but I think it makes to support 2-3 last versions so people have time to migrate.

[BurntSushi]

@ignatenkobrain Thank you. That is an extremely helpful data point.

[Object905]

Also now encoding_rs has simd-accel feature, so it would be nice to add it in simd-accel feature as well.