add CI

[marshallpierce]

add CI

[marshallpierce]

I see what you did there. ;) 1.23 sounds fine.

I have a variety of breaking changes brewing in the back of my head and I'll probably bump the version at that time but that will be months from now.

[marshallpierce]

Sure, those are both great things to do; I just haven't gotten to them yet (PRs welcome!). It's lower priority for me than wrapping up the long-suffering open PRs (pending me having the IRL time availability), but definitely a good idea.

This library isn't particularly demanding about needing the latest rust features (though I plan on adding SIMD support), but I also don't want to end up with a huge test matrix of versions. Is "latest & previous stable" enough? Or even just "latest stable"?

[BurntSushi]

IMO, libraries that are intended to be used in a wide variety of applications should be fairly conservative about their minimum supported Rust version. At this point, I think the trend is that you should test at least a specific pinned version of Rust and not an automatically moving target like stable. The key point here is that it requires a conscious and deliberate change to the CI configuration when the code requires a newer version of Rust. If you don't pin a specific Rust version, then it basically requires users of your crate to perform a research task to figure it out, if they care. (I am someone who cares, because I want to be able to declare in my project's README that you need "at least Rust 1.x to be able to compile this project.")

There are separate questions about whether increasing the minimum supported Rust version is also a semver incompatible change, but there is no widespread consensus on this, so I'm not advocating any specific policy on that front. Mostly, I'm just asking for it to be easily discoverable which version of Rust this crate targets.

I will see about submitting a PR that adds a basic CI config, but you will need to actually enable it on your end, e.g., via Travis CI. Have you done something like that before, or would you like me to help you do it?

[marshallpierce]

I see your point. Is there data available about adoption of new Rust toolchain versions so library authors can make such choices without being quite as much in the dark?

I've avoided Travis in favor of other CI platforms for my own projects because I reflexively avoid things that enforce a technical monoculture (in Travis's case, it's GitHub-only) but given that this project is firmly ensconced in GitHub-land, Travis will do fine.

[BurntSushi]

Is there data available about adoption of new Rust toolchain versions so library authors can make such choices without being quite as much in the dark?

No. Everyone is winging it. Once Rust gets LTS releases, I suspect there will be a stronger push to unify around a specific Rust version.

If you just want to pick something, I selfishly propose 1.23, since it's what ripgrep is targeting, and I know that this crate compiles on 1.23. :-) To be clear though, the most important thing, IMO, is not exactly which version you pick, but rather, that you pick one and make it discoverable. How often (or when) you bump that version is a totally separate concern. My own opinion there is to be conservative---especially with crates like base64 that find their way into everything---but there's no strong consensus on this point. I do feel that there is fairly widespread consensus that CI should have a specific version pinned though.