Regression in `set_scheme` for 2.1.1 vs 2.1.0

[alexcrichton]

Cargo's internal test suite is unfortunately failing after the update to url 2.1.1, and one thing we've narrowed down so far is that the behavior of this changed between 2.1.0 and 2.1.1:

use url::Url;

fn main() {
    let mut url = Url::parse("git://github.com/foo/bar").unwrap();
    println!("{:?}", url.set_scheme("https"));
}

On 2.1.0 this succeeded but on 2.1.1 this is now failing.

Is this an intended change or perhaps an accidental bug? If it's intended, is there a way we can get this working?

[alexcrichton]

Er sorry, and to be clear, it's set_scheme that's changing behavior, parse works on both versions.

[jdm]

This looks like a deliberate change in 7efdc53.

[alexcrichton]

In the case that this is deliberate, is there perhaps a workaround that we can implement?

[jdm]

let url_str = "git://github.com/foo/bar";
let git_url = Url::parse("git://github.com/foo/bar").unwrap();
let https_url = Url::parse(url_str.replace("git", "https")).unwrap();

Would that work for you?

[SimonSapin]

If you want to go with string manipulation, consider something like ["https", &git_url[url::Position::AfterScheme..]].join() in case the substring https occurs in some other part of the URL.

[tmccombs]

1. What was the motivation for this change?
2. Should such a breaking change be part of a patch release?
3. The documentation only says set_scheme fails if:
   • The new scheme is not in [a-zA-Z][a-zA-Z0-9+.-]+
   • This URL is cannot-be-a-base and the new scheme is one of http, https, ws, wss, ftp, or gopher
     And I don't think either is the case here. If this is intended behavior should the documentation be updated?

[valenting]

1. What was the motivation for this change?

Getting all the URL web-platform tests to pass

2. Should such a breaking change be part of a patch release?

In retrospect it would have been probably better to be in a dot release, but it wasn't immediately obvious at the time that we were breaking a common use case.

3. The documentation only says set_scheme fails if:
     And I don't think either is the case here. If this is intended behavior should the documentation be updated?

Yes, we should update the docs to reflect all of the cases in https://url.spec.whatwg.org/#scheme-state

[dekellum]

So yank 2.1.1 and release 2.2.0, already.

[SimonSapin]

What would that achieve? Cargo treats them the same.

[dekellum]

No it doesn't. And if it did, SemVer is still worth following.

[SimonSapin]

https://semver.org/#spec-item-8

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.

Does a “change […] to the public API” also include behaviors, or only signatures?

For a library documented as implementing a living standard (which doesn’t have version numbers and changes over time), should changing the behavior to catch up with a specification change be “considered backwards-incompatible”?