Tracking issue for rust-url 2.0

[SimonSapin]

For a while now we’ve been discussing some possible breaking changes and I’ve been reluctant, to avoid dealing with moving the ecosystem to a semver-incompatible version. However it’s probably time to do it anyway, in particular to get serde 1.0 support in the url crate itself. To avoid doing multiple such migrations, it would be nice batch breaking changes together.

This is blocked on

• Having a viable migration path for Servo

  • Upgrading Servo from Hyper 0.11 (which uses rust-url 1.x) Update hyper to 0.12 servo#19825
  • Upgrading https://crates.io/crates/webdriver
  • Upgrading https://crates.io/crates/ws
  • Ideally we would demonstrate building Servo with a v2.0 branch of rust-url before publishing rust-url 2.0.0 to crates.io.

This would unblock

• Removing serde_url
  • Closing Implement Serialize and Deserialize on ParseError #386
  • Closing [Question] How to deserialize Vec<Url> #420
• Closing Add Cargo feature query_encoding_2 to use encoding_rs crate #446
• Deserializing a URI requires parsing it servo#20412

Changes to consider

Not necessarily blockers for 2.0.0.

Update with current spec and tests

… because this might lead to API or behavior changes.

• Track spec changes somehow #163
• Align with latest of web-platform-tests #290

Breaking API changes

• Replace () error types with specific types that implement Error #299
• Move serde 1.0 support in-crate #304 / Drop old serde support and move serde 1.0+ support in-crate #303
• Rename Url::join? Behaviour of Url::join #333
• Return Result<{Self,&Self,&mut Self}, _> instead of Result<(), _> to allow method chaining #375
• Add PathSegmentsMut::finish #380 / PathSegmentsMut has no finish method like UrlQuery #363
• percent_encoding::EncodeSet cannot be boxed #388
• Migrate to encoding_rs crate? #444 (remove rust-encoding support)
• Use of std::ascii::AsciiExt causes warnings #455 (bump Rust version requirement)
• Move the url::quirks module to Servo #460
• Remove ParseOptions::syntax_violation_callback? #462
• Getting rid of rustc-serialize #506
• Remove everything marked as deprecated
• Stop re-exporting entire crates, make crate dependencies private where possible
• Others?

Behavior changes

Some of those might arguably be considered breaking. Or maybe not.

• What to do when URLUtils.protocol setter change the scheme "type" #85
• Setting the scheme to "file" should fail if there's a host or port #278
• Url.to_file_path() doesn't produce UNC path on Windows #450
• Check / reconsider to_file_path behavior with %2f #461
• Parsing the hostname "xn--" returns an empty hostname, but doesn't throw an error when a hostname is required #373
• Round-trip parsing for a URL string results in different outcomes #391
• Fix to_file_path for relative paths with drive letters #442

Non-breaking changes

… maybe worth looking at while I’m spending time on rust-url:

• Use rustfmt. The default style is probably more stable these days. CC Don’t rustfmt, yet #336
  • Enforce it on CI?
• Mutate segments throught PathSegmentsMut #383

Unsure if breaking

• Extend query parameters with Display types rather than &str? #348
• IDNA API does not feel optimal when reusing Errors type #359
• PathSegmentsMut has no finish method like UrlQuery #363

Potential breaking changes for the idna crate

• New versions of IDNA UTS #46 have more flags #486
• Reconsider error handling, CC IDNA API does not feel optimal when reusing Errors type #359

Potential breaking changes for the percent_encoding crate

• Encode sets as const values of a single type, instead of types implementing a trait

[atouchet]

Servo is now using hyper 0.12.

[est31]

rustc-serialize should probably be put onto the list, too: #506

[killercup]

Hey, for an internal project we wanted to have a url crate with some of the things listed here. I forked this repo and made some changes, mostly removing rustc-serialize and adding serde 1.0, which you can find here. This is not meant to replace this crate, but to as soon as possible rexports all of url 2.0 and get deprecated :)

Are you okay with me publishing this fork to crates.io? We'll want to publish some crates depending on this.

[SimonSapin]

I mean, if publishing a fork is what you need to get other work unblocked I don’t really have a reason to stop you.

That said, Just Making url 2.0 Already is probably a better outcome. I’ve just been putting it off because the list above looks so daunting. But maybe you or other people can help. I’ve pushed a 2.0 branch which for now is the same as master. Feel free to make PRs into that branch for any of the above (or more). The changes your already have in your fork would be a good start.

The key is we don’t have to do everything in the list. While batching breaking changes is better to avoid the need to do 3.0 too soon, if no one has implemented a particular change after some time maybe it’s wasn’t that important in the first place.

[killercup]

That said, Just Making url 2.0 Already is probably a better outcome.

Definitely.

I’ve just been putting it off because the list above looks so daunting.

I can relate to that very much! And since url is a pretty major crate the barrier to just releasing a new major version is pretty high I imagine.

I'm gonna publish my fork so our internal stuff can easily depend on it (and I so that I can feel like I did something this week). I'll probably also keep doing weird stuff there just to experiment with some APIs, and release a new version until I either hit 0.99.0 or am actually happy with the code.

I hope to have the time to slowly merge to "good" parts back into your 2.0 branch. Actually, anyone is welcome to just take my changes and merge them over!

[SimonSapin]

• https://crates.io/crates/url/2.0.0
• https://crates.io/crates/idna/0.2.0
• https://crates.io/crates/percent-encoding/2.0.0