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.

[lifthrasiir]

Position update:

I have gone through possible resolutions without breaking the backward compatibility for recent weeks. I thought legacy-serde is the most plausible option, but at the detailed look it is unusable because Chrono 0.3.0 and 0.3.1 shares the same feature flag (serde) for different versions of Serde. Another attempt has involved making another shim crate (aptly named as chrono-03-hack-for-legacy-serde-that-is-still-living-and-kicking) which provides both Serde 0.9 and 1.0 interfaces depending on the version used [1]. After frenzy hacks to test this without setting a new crates.io instance up (N.B. in fact this worked really well), I ultimately gave up because Cargo cannot influence the version of the shim crate from the version of Serde used.

[1] This would make Chrono to use only one version of Serde when requested. That is, if some dependencies expect Serde 0.9 and others expect 1.0, it would always try to use 1.0. Note that this is the exact situation of which I was afraid!

So... It seems that we have the only option: upgrade Chrono and forget about unfortunate crates that are stuck at Serde 0.9 (yes, I still feel uneasy about this but that's a life). I still think that this is suboptimal, but it is now evident that some crates won't upgrade to Serde 1.0 in the foreseeable future anyway so I don't want to continue this turmoil any longer. I still need justifications to release 0.4.0, so in this weekend I have worked (and am still working) on important API additions that were originally prepared for 0.3.2. I think 0.4.0 will be out in this week---sorry for inconvenience, and stay tuned.

[SergioBenitez]

@lifthrasiir There is an obvious answer here that has been proposed multiple times: yank 0.3.1 and publish 0.4.0 with serde 1.0. What you are proposing is not okay; "that's life" is not good enough. Reliable dependency management via Cargo only works if we give meaning to version numbers. This is justification to release 0.4.0. Why are you holding steadfast to a position that harms the ecosystem as a whole?

[quodlibetor]

@SergioBenitez considering that 0.3.1 has already been released (almost two months ago) and that lifthrasiir has agreed to release a 0.4 soon I think that the majority of the damage has been done. The question now is what to do to make the upcoming changes as easy as possible.

The "that's life" was, I think, in reference to the fact that @lifthrasiir can't find a way to backwards-compatibly support both serde 0.9 and 1.0. They're trying really hard to find a solution that does the least harm, not working out of a position of disregard for the ecosystem.

@lifthrasiir You've mentioned a couple of breaking API changes that will improve chrono, if they're small enough would it be possible to release those as a 0.4.0 release which includes the serde 1.0 update, and reserve the release announcement for a 0.4.1 that contains the new APIs you're trying to implement? This will actually make it easier for crates that are stuck at serde 0.9: they'll know that they can just stick to chrono 0.3 and everything will work.

[sgrif]

can't find a way to backwards-compatibly support both serde 0.9 and 1.0. They're trying really hard to find a solution that does the least harm, not working out of a position of disregard for the ecosystem.

"We couldn't find a way to support both" does not justify breaking existing code, nor is the solution chosen the one that does the least harm. I do agree that 0.3.1 should be yanked and released as 0.4.0 (as has been stated in the past)

[quodlibetor]

I also agree that 0.3.1 should be yanked and released as 0.4. I was more responding to the fact that Sergio seemed to think that lifthrasiir was responding to the current situation with "that's life", which (I think) was the opposite of the intended meaning.

[anowell]

I agree the damage is done, and by now there may be crates that expect serde 1.0 and chrono 0.3.1, so I'm not gonna jump into the debate around yanking it; I prefer to comment on the future.

I say this empathetically as someone who also intentionally, but regrettably broke semver (albeit with less impact): my concern here is that while this is described as an exceptional/rare breaking change, the general tone suggests that breaking changes may happen again if the changes don't feel substantial enough to merit a bigger version bump. Hence I'm inclined to continue to lock chrono to a specific version (even when I do upgrade to 0.4.0) to avoid this in the future. I'm on the fence as to whether that is an overreaction, but it is why I believe this is harmful to the ecosystem. So mostly, I'd love assurance that chrono will adhere to semver going forward insofar as is reasonably possible, even if it seems like an insubstantial major/minor version bump.

Edit: In all cases, thank you for this crate!

[SergioBenitez]

@quodlibetor I'm not sure if I misinterpreted something. I was responding to the following:

So... It seems that we have the only option: upgrade Chrono and forget about unfortunate crates that are stuck at Serde 0.9 (yes, I still feel uneasy about this but that's a life).

There isn't one option, and it's not okay to "forgot about unfortunate crates that are stuck at Serde 0.9". Isn't the "that's life" bit applied here? If it's being applied to something else, it's placed in an unfortunate position in the prose.

There is a solution that works widely, albeit some would need to upgrade from 0.3 to 0.4. But this should have been the case in the first place. Regardless, because of this mistake, crates are going to break. But we should choose an approach that gives back control to crate authors. A crate author should decide when breaking changes occur, not the libraries on which it depends.

[durka]

Well, it's true: crates that don't want to upgrade to serde 1.0 won't be able to use chrono 0.4.0. They also aren't able to use the current 0.3.1, so I'm not quite understanding @lifthrasiir's dilemma, but they've already stated their intention to release 0.4.0 with serde 1.0 so I think you're being a little harsh. Personally I agree that there doesn't need to be any other "motivation" to bump the version, but as long as 0.4.0 gets released and 0.3.1 gets yanked I'm happy.

[quodlibetor]

Meant to cancel writing a comment, realized it didn't add anything, accidentally clicked "close".

[sgrif]

I agree the damage is done, and by now there may be crates that expect serde 1.0 and chrono 0.3.1, so I'm not gonna jump into the debate around yanking it;

To be clear, yanking a crate does not prevent builds which already depend on it from continuing to work.

[durka]

Thanks so much for clearing this up, @lifthrasiir.

…

On Wed, Jun 21, 2017 at 2:05 PM, Kang Seonghoon ***@***.***> wrote: Closed #146 <#146> via fe529c8 <fe529c8> . — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#146 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n3NIw78GV4llDBULqyOUybayOQcxks5sGVtggaJpZM4NR2h-> .