Better usage of SemVer

[heartsucker]

The upgrade from 0.3.0 to 0.3.1 broke several of my projects because the dependency on serde 0.9 to 1.0 caused API incompatibilities. It would be nice if you guys were more mindful of this in the future.

[sgrif]

Getting lots of reports about this on Diesel as well. It'd be great if 0.3.1 could be yanked and the change could be re-released as 0.4.0 instead.

[lifthrasiir]

I apologize for any breakage, but this is intentional (and very exceptional---this should be the only occurrence of this kind of release). Please let me explain why.

I have received a lot of complaints when Chrono went from 0.2.25 to 0.3.0; the crates are (temporarily) split around the version of popular dependencies they depend on, and you cannot (currently) have multiple dependencies of the same crate with differing versions---if this were possible I would have immediately done this! This split-brain situation has occurred several times in the past, but Chrono 0.3.0 was particularly problematic because it coincided with Serde 0.9. I monitor the IRC for any mention of Chrono and the resulting chaos was quite annoying.

After 0.3.0 I have been convinced that the split-brain situation is hard to reconcile with the semantic versioning alone, especially because Chrono is also a relatively popular crate (so making a minor release makes the split-brain worse). A new release was made with this in mind: It is better to make everyone use Serde 1.0 (after a short burst of breakage) than keeping the semantic versioning, and technically Chrono does not have to strictly adhere to the semver as it's pre-1.0. I know, this is probably the one-off chance, but Serde 1.0 is the only significant dependency that Chrono supports, so it is a kind of reasonable bet.

To the end my current subjective experience suggests that the resulting breakage is no worse than the previous release. But I might be missing something---for example I can't imagine if the place where people ask about Chrono has been changed in mere 3 months, but this is technically possible. I want to hear about other crate authors' experience, especially comparing with Serde 0.9.

[dtolnay]

For url we are planning to support Serde 1.0 in a non-breaking release while preserving compatibility with old Serde: servo/rust-url#327. It is using these Serde shims.

[lifthrasiir]

@dtolnay Very interesting. I wasn't aware of those shims; I'll look for using them in the future release.

[golddranks]

I think that releasing a SemVer-incompatible release is strictly worse than releasing a new major (or 0.x minor). Releasing a new version that leads to a temporary split is unfortunate for library authors that depend on Chrono, as they may have to wait for their other dependencies to update or maintain two versions momentarily. However, releasing a breaking chance like this leads to the builds of the users of those libraries breaking, which is a lot worse – why should the users have to stress over the dependencies of dependencies. That forces the dependent library authors to fix specific versions, to be able to provide better guarantees of the build not breaking themselves, as they can't trust the SemVer of their dependencies.

[mrhota]

http://semver.org/#spec-item-4

[dtolnay]

@mrhota Rust and Cargo follow a different convention. See http://doc.crates.io/specifying-dependencies.html#caret-requirements

[durka]

I can't use chrono if running cargo update means that I get new errors about missing #[derive(Serialize)] (since the rest of my code still depends on serde 0.9), which happened today. I can't understand the downside of following the SemVer rules and incrementing the minor version.

[durka]

Exactly because chrono is a relatively popular crate, hiding a breaking change such as this in a patch release makes cargo update unreliable for everyone. I'm unclear as to how you think this is fine.

[heartsucker]

Maybe you should just do as @dtolnay said and release a new patch version with the serde shims added since clearly this is a problem for everyone.

[quodlibetor]

I would definitely merge a patch that supports the shims, and (if I have the rights on crates.io) release a 0.3.2 with that. I'm planning on trying to implement them as soon as I have some free time, but I've been busy (moving + dayjob have been rough) and this weekend isn't looking great for me either :-(

This is @lifthrasiir's project so I don't want to just counteract his opinion on semver.