release regex 1.0 (May 1, 2018)

[BurntSushi]

I think the 0.2 release has baked long enough. I propose that regex 1.0 be released on May 1, 2018.

Here are the key breaking changes (all supremely minor) I'd like to make:

• Increase the minimum Rust version to 1.??.
• Establish a policy around bumping the minimum Rust version. I would like to propose that new patch releases (1.x.y) should never increase the minimum Rust version required to compile regex, but that new minor version releases (1.x) may increase the minimum Rust version required to compile regex.
• Disable octal syntax by default. Today, Regex::new(r"\1").unwrap().is_match("\u{1}") evaluates to true. Instead, I'd like it to emit an error that backreferences are not supported. We will provide a method on RegexBuilder to opt into the old syntax with octal escape sequences supported.
• Ban (?-u:\B) from use in Regex::new, since it is permitted to match invalid UTF-8 boundaries. We, of course, continue to allow it for bytes::Regex::new. (?-u:\b) remains legal in Regex::new, since it cannot match invalid UTF-8 boundaries.
• Remove the impl From<regex_syntax::Error> for regex::Error definition. The fact that this exists was an oversight, and it actually causes regex-syntax to be a public dependency of regex, which we very much do not want to happen.
• As noted by @cuviper, we may some day want to support non-std but core/alloc-only use cases. To make this happen, we'll need to gate things on a std feature that is enabled by default. We need to add this feature in 1.0 and gate the entire crate on it. If we didn't, and added this gate in the future, then existing uses of default-features = false would likely break, which would be a breaking change.

[jethrogb]

Establish a policy around bumping the minimum Rust version. I would like to propose that new patch releases (1.x.y) should never increase the minimum Rust version required to compile regex, but that new minor version releases (1.x) may increase the minimum Rust version required to compile regex.

I'd advocate against this. Requiring a newer Rust version should be considered a breaking change.

Discussion on this topic rust-lang/api-guidelines#123

[BurntSushi]

@jethrogb It's a compromise. The topic has been discussed to death. I frankly don't have the energy to continue discussing it.

[BurntSushi]

My thoughts on the matter are here: rust-lang/api-guidelines#123 (comment)

[BurntSushi]

I frankly don't have the energy to continue discussing it.

Let me rephrase this, because I do want to discuss it if there are things that I've missed or haven't thought about deeply. In particular, I would appreciate if further discussion built off of my thoughts here. If I'm missing something, then let's talk about it, but let's please try to avoid rehashing things.

[jethrogb]

My hope is that a community-wide decision on the matter can be reached (possibly as a part of the API guidelines initiative) before committing to a particular strategy just for this crate.

[BurntSushi]

I don't see how that's going to happen. Did you read my comment that I linked? The regex crate will not be the first to adopt this policy.

[WiSaGaN]

I'd advocate against this. Requiring a newer Rust version should be considered a breaking change.
Discussion on this topic rust-lang/api-guidelines#123

@jethrogb in that case, you can just pin to the minor version, which still allows updates of bugfix without upgrading your compiler.

[jethrogb]

@BurntSushi but it will be (I think) the first crate under the rust-lang umbrella to adopt that policy, no?

@WiSaGaN Not if you have dependencies that silently update their dependency version requirements (which should be ok because they're semver compatible)! See the linked thread for additional discussion.

[WiSaGaN]

@jethrogb If the dependency crates' owners decides to upgrade to regex 1.0, I think they should decide whether they should allow for minor version update or not depending on their own compatibility promises. They should specify the minor version of regex if they promise a stable minimum rustc version.

As long as regex is explicitly spelling out the version convention, I think the other crate owner should take the responsibility to take into account the fact. Have I missed something?

[jethrogb]

Have I missed something?

@WiSaGaN Yes. The point of semver is to not have to meticulously read each dependency's "compatibility policy" because it's spelled out in semver.

[BurntSushi]

This conversation is frustrating. Semver does not spell out anything other than a high level interpretation of version numbers. There is already broad precedence in the Rust ecosystem that certain types of technically backwards incompatible changes aren't actually backwards incompatible when reasoning about semver. Moreover, the assumption that bumping the minimum Rust version is even a semver incompatible changed is contested, and acting like it isn't is not productive.

I will stress this again: let's please table this discussion unless you have something new to add.

@jethrogb Your distaste has been acknowledged. I don't find any of your arguments compelling because they don't bring anything new to the table. My plan at the moment is to continue as planned, and if that in practice causes problems in the ecosystem, then we can re-evaluate that policy.

[jethrogb]

@BurntSushi Sorry, it wasn't my intention to have this discussion in this thread all over again. I'm fine with having the discussion in rust-lang/api-guidelines#123 and I suggest @WiSaGaN express their arguments over there is well.

My main gripe is with a crate under the rust-lang umbrella (this crate) unilaterally defining what the policy is before consensus is achieved/a decision is made in that issue.