The changelog has the details: regex/CHANGELOG.md at master · rust-lang/regex · GitHub
Happy new year! The changelog hopefully details all of the breaking changes. I'm releasing 0.2 first to make sure everything is kosher, and a 1.0 should be soon to follow. Folks upgrading to 0.2 and providing feedback is most appreciated. 
Here's something that will really bake your noodle: with regex 0.2 comes a bump in the minimum supported version of Rust to 1.12. There has been some debate over whether that's a breaking change or not. But if your crate's minimum supported version is less than 1.12, does that mean bumping to regex 0.2 is actually a breaking change? And is there a difference between the minimum supported version of Rust and the minimum required version of Rust?
9 Likes
As one of the most visible Rust crates, this is great to see. On behalf of (hopefully) everyone who uses Rust: thank you again for all your exemplary work.
To reiterate my position on the question: yes, it is a breaking change. So long as depending on regex 0.2 over 0.1 can cause Cargo to automatically select a dependency that will cause code that used to compile to no longer compile, it's a breaking change. Because you're breaking someone else's code.
Edit: Also, you absolutely can support one version, but only require an earlier version. That said, I usually make the two the same because I can't think of a compelling reason not to.
2 Likes
If, one day you require Rust 1.13, please don't use the question mark operator until this is fixed.
It's perfectly fine to use it if it doesn't result in performance regressions.
Really? If I say that 1.12 is the minimum supported version when 1.6 is the required version, then I've allowed all changes to Rust up through 1.12 to be used inside my crate without it qualifying as a breaking change. That seems very compelling to me. Just because I'm not using newer features or APIs now doesn't mean I never will!
The problem here is that your code can still break if you happened to ignore the documentation that states 1.12 is the minimum version and started relying on, say, it compiling for 1.6.
Aye. This is part of why I've always wanted the required Rust version to be specified in the code somewhere. Currently, it's way too easy for authors to accidentally require a newer version of Rust (or dependencies) than they'd intended, and too easy for users to use code in an environment that isn't actually supported.
4 Likes
The way we solve this in Python is to use trove classifiers to specify which versions of Python a package support, a badge to make it visible and obvious on PyPI and Github, and then use tox to explicitly test against each of those versions that are supported.
It's something I suggested on another thread.
The only issues I see with using this model is that Rust releases versions about 8 times as fast as Python (~8 per year vs. ~1 per year) so that would result in many, many Travis builds to test against all versions (but maybe that is really what should be happening anyway if we are espousing support for all of them).
An alternative could maybe be that the crate is tested on the lowest stable and highest stable version it supports to try to stop accidental use of new features.
3 Likes
Just curious, is there an eventual plan to make this crate part of the std library? As someone relatively new to rust, I was rather surprised to discover that regular expression support wasn't part of the core functionality offered with rust.
As far as I remember, there are plans to put regex into std. However, more generally speaking:
Because it is so easy to add external dependencies from crates.io, the Rust core team has been very cautious in adding completely new functionality to the standard library. Basically, the union of what different people expect in std (probably because of the stdlibs of other languages they're familiar with) would lead to way too much code for the team to maintain reliably.
Also, there are topics where it's deceptively easy to add something working, only to discover later that the design must be incompatibly changed to actually work correctly, or efficiently. Committing a library to std means that it must stay backwards compatible "forever", while an external crate is free to bump major version numbers.
That said, recently there has been a lot of discussion about a way to bring a little more order into the multitude of packages available on crates.io, through better ranking, community rating, or more blessing of "go-to" crates in the rust-lang-nursery namespace. C.f. this RFC proposal and the discussion about Eric Raymond's second Rust related post.
1 Like
Nope. There are no plans (and there never have been).
To add more context (sorry I was on mobile earlier):
regex is part of the core functionality offered with Rust by virtue of being a member of the rust-lang organization. This comes with a promise that this library will be maintained by the Rust teams and will work on the same platforms that Rust targets. Using it is a piece of cake: just add the relevant line to your Cargo.toml. regex was once shipped as part of the Rust distribution, and removing regex from the Rust distribution was the best thing that ever happened to it. Namely, it could evolve independently of everything else. So long as it stays outside of std, it can continue to evolve.
5 Likes
Thanks, this helps me understand what the goal is then. I'll assume then that this is similar to Go's model where the standard library provides most of the foundational functionality, but they then prevent additional functionality in additional packages that are hosted by the Go project in their repository, but are not considered part of the standard library (e.g. net, sys, etc.).
