3 ms·

> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often. I indeed di

> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often. I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of strictly obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the release in question. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict. [1] https://github.com/chronotope/chrono https://github.com/chronotope/chrono [2] https://github.com/chronotope/chrono/issues/146#issuecomment-309276715 https://github.com/chronotope/chrono/issues/146#issuecomment... [3] https://github.com/chronotope/chrono/issues/156 https://github.com/chronotope/chrono/issues/156 [4] https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#040-2017-06-22 https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#...

chronogram 3y ago
I understand from the author perspective that everything below 1.0 is subject to change, from the hobby user perspective I see 0.3 to 0.3.1 and think "oh bug fix, that means I won't read it" without expecting semver.
- lifthrasiir 3y ago
  All those things happened when the Rust crate ecosystem was still much in flux (back in 2017), and I had some good reasons: - Serde had made a very slight but breaking change in 1.0, and at that time I think it was impossible to support both Serde 0.9 and 1.0 in a single crate without a hacky workaround (which I only learned much later). So if I had to pick only one version to support, it ought to be 1.0 as the change was trivial to resolve. - Cargo's use of semantic versioning is, while documented, not strictly conforming because 0.x.y is considered compatible with 0.x.z where x > 0 and y < z [1]. - People complained a lot when Chrono went 0.2.x to 0.3.0 as well. This is IMO the biggest reason to issue a breaking change; if people would complain in either way, I wanted to make a choice that benefits the whole Rust ecosystem more. If this happen today I would agree that I shouldn't have done that, but I think it was not that clear cut at that time. [1] https://semver.org/#spec-item-4 https://semver.org/#spec-item-4

chronogram 3y ago

I understand from the author perspective that everything below 1.0 is subject to change, from the hobby user perspective I see 0.3 to 0.3.1 and think "oh bug fix, that means I won't read it" without expecting semver.

lifthrasiir 3y ago
All those things happened when the Rust crate ecosystem was still much in flux (back in 2017), and I had some good reasons: - Serde had made a very slight but breaking change in 1.0, and at that time I think it was impossible to support both Serde 0.9 and 1.0 in a single crate without a hacky workaround (which I only learned much later). So if I had to pick only one version to support, it ought to be 1.0 as the change was trivial to resolve. - Cargo's use of semantic versioning is, while documented, not strictly conforming because 0.x.y is considered compatible with 0.x.z where x > 0 and y < z [1]. - People complained a lot when Chrono went 0.2.x to 0.3.0 as well. This is IMO the biggest reason to issue a breaking change; if people would complain in either way, I wanted to make a choice that benefits the whole Rust ecosystem more. If this happen today I would agree that I shouldn't have done that, but I think it was not that clear cut at that time. [1] https://semver.org/#spec-item-4 https://semver.org/#spec-item-4