5 ms·

According to the survey, ~16% of people experience breakage with minor upgrades. Isn't this a pretty serious violation of semver?

by panic 10y ago

jjnoakes 10y ago
I don't know the details in rust's case, but I wouldn't consider it a violation of semver if the code which broke in a minor update was doing bad things (maybe accidentally exploiting a bug or limitation in the language or implementation, probably by violating some requirement that wasn't checked properly, etc) and simply couldn't be correct code if left alone.
- panic 10y ago
  How do you define a "bad thing"? The semver spec is quite clear about "even the tiniest backwards incompatible changes" (http://semver.org/#if-even-the-tiniest-backwards-incompatible-changes-to-the-public-api-require-a-major-version-bump-wont-i-end-up-at-version-4200-very-rapidly http://semver.org/#if-even-the-tiniest-backwards-incompatibl...) requiring a major version bump.
  - Manishearth 10y ago
    Rust has its own definition of what it defines to be stable. Soundness fixes and bug fixes do not count, though as much as possible they will try to fix them in a way that breaks very little. http://blog.rust-lang.org/2014/10/30/Stability.html http://blog.rust-lang.org/2014/10/30/Stability.html
  - lifthrasiir 10y ago
    Cargo does not (yet) ensure that the library maintainer did follow the semver's doctrine.
    - Argorak 10y ago
      But there are people working on it. https://github.com/semantic-rs https://github.com/semantic-rs
  - jjnoakes 10y ago
    It may not be considered a backwards incompatible change to rust if it no longer compiles invalid code. If the code never worked correctly, but silently compiled, one would think a breaking change was welcomed.
  - steveklabnik 10y ago
    Semver does not define what a "compatible" vs "incompatible" change means, though. Manish linked to how we define it, but SemVer specifically leaves that up to the project.
Manishearth 10y ago
I believe (but cannot verify) that these breakages were due to libraries breaking, especially libraries which evolve in lockstep with Rust internals like aster. The main reason I believe this is because each release is tested against the entire ecosystem, and stability regressions are fixed. The only time that breakages in the ecosystem are okay are during a soundness fix where the broken library was doing something unsound.
- mook 10y ago
  Doesn't the large portion of people using unstable libraries / things depending on unstable internals mean that the versioning isn't covering a large enough API? I feel like blaming the user isn't really going to help make the ecosystem more stable. (Context: I went through the tutorial at one point and got really fed up that it wasn't possible to do it without involving crates because there wasn't any random number generation in the standard library.) I of course understand that you folks are still working hard on it and it'll come in time; it's just that all other recent languages (Go, Ruby, Python, heck even the . Net and JVM ones) come with a large and usable standard library.
  - steveklabnik 10y ago
    > isn't covering a large enough API? We stabilize lots of stuff every release, but we also don't want to stabilize things that aren't ready. Once we do, we're stuck with that interface forever. A significant portion of nightly users are on it due to compiler plugins, even for libraries that work on stable, because it makes development a bit easier. Stabilizing those immediately would mean stabilizing compiler internals, which is a pretty huge drawback. We have plans for addressing that specifically, as well as for the more general "libraries change" problems. They will come as part of an actual announcement, not a leaked first draft blog post :)
  - dikaiosune 10y ago
    I came from languages where a big standard library was de rigeur (python, java), and I quite like rust's approach personally. For one thing, having RNG in the standard library would make it much harder with rusts stability guarantee to iterate on the API design in meaningful ways. For another, it's way easier to maintain external dependencies in a rust project than in others. Cargo is like night and day compared to pip, for example.
lifthrasiir 10y ago
The Rust compiler has been very stable after 1.0. The issue lies in the ecosystem, and people is still figuring out the best design and/or solution for doing things, while occasionally breaking them. The biggest ecosystem breakage so far was termed "libcpocalypse", which was a massive hit for everyone (transitively) depending on libc crate for FFI. The proper resolution is still in under way [1]. [1] https://internals.rust-lang.org/t/solve-std-os-raw-c-void/3268 https://internals.rust-lang.org/t/solve-std-os-raw-c-void/32...
llogiq 10y ago
This percentage includes people using explicitly unstable things (e.g. me).

According to the survey, ~16% of people experience breakage with minor upgrades. Isn't this a pretty serious violation of semver?

by panic 10y ago

According to the survey, ~16% of people experience breakage with minor upgrades. Isn't this a pretty serious violation of semver?

jjnoakes 10y ago

I don't know the details in rust's case, but I wouldn't consider it a violation of semver if the code which broke in a minor update was doing bad things (maybe accidentally exploiting a bug or limitation in the language or implementation, probably by violating some requirement that wasn't checked properly, etc) and simply couldn't be correct code if left alone.

panic 10y ago
How do you define a "bad thing"? The semver spec is quite clear about "even the tiniest backwards incompatible changes" (http://semver.org/#if-even-the-tiniest-backwards-incompatible-changes-to-the-public-api-require-a-major-version-bump-wont-i-end-up-at-version-4200-very-rapidly http://semver.org/#if-even-the-tiniest-backwards-incompatibl...) requiring a major version bump.
- Manishearth 10y ago
  Rust has its own definition of what it defines to be stable. Soundness fixes and bug fixes do not count, though as much as possible they will try to fix them in a way that breaks very little. http://blog.rust-lang.org/2014/10/30/Stability.html http://blog.rust-lang.org/2014/10/30/Stability.html
- lifthrasiir 10y ago
  Cargo does not (yet) ensure that the library maintainer did follow the semver's doctrine.
  - Argorak 10y ago
    But there are people working on it. https://github.com/semantic-rs https://github.com/semantic-rs
- jjnoakes 10y ago
  It may not be considered a backwards incompatible change to rust if it no longer compiles invalid code. If the code never worked correctly, but silently compiled, one would think a breaking change was welcomed.
- steveklabnik 10y ago
  Semver does not define what a "compatible" vs "incompatible" change means, though. Manish linked to how we define it, but SemVer specifically leaves that up to the project.

Manishearth 10y ago

I believe (but cannot verify) that these breakages were due to libraries breaking, especially libraries which evolve in lockstep with Rust internals like aster. The main reason I believe this is because each release is tested against the entire ecosystem, and stability regressions are fixed. The only time that breakages in the ecosystem are okay are during a soundness fix where the broken library was doing something unsound.

mook 10y ago
Doesn't the large portion of people using unstable libraries / things depending on unstable internals mean that the versioning isn't covering a large enough API? I feel like blaming the user isn't really going to help make the ecosystem more stable. (Context: I went through the tutorial at one point and got really fed up that it wasn't possible to do it without involving crates because there wasn't any random number generation in the standard library.) I of course understand that you folks are still working hard on it and it'll come in time; it's just that all other recent languages (Go, Ruby, Python, heck even the . Net and JVM ones) come with a large and usable standard library.
- steveklabnik 10y ago
  > isn't covering a large enough API? We stabilize lots of stuff every release, but we also don't want to stabilize things that aren't ready. Once we do, we're stuck with that interface forever. A significant portion of nightly users are on it due to compiler plugins, even for libraries that work on stable, because it makes development a bit easier. Stabilizing those immediately would mean stabilizing compiler internals, which is a pretty huge drawback. We have plans for addressing that specifically, as well as for the more general "libraries change" problems. They will come as part of an actual announcement, not a leaked first draft blog post :)
- dikaiosune 10y ago
  I came from languages where a big standard library was de rigeur (python, java), and I quite like rust's approach personally. For one thing, having RNG in the standard library would make it much harder with rusts stability guarantee to iterate on the API design in meaningful ways. For another, it's way easier to maintain external dependencies in a rust project than in others. Cargo is like night and day compared to pip, for example.

lifthrasiir 10y ago

The Rust compiler has been very stable after 1.0. The issue lies in the ecosystem, and people is still figuring out the best design and/or solution for doing things, while occasionally breaking them. The biggest ecosystem breakage so far was termed "libcpocalypse", which was a massive hit for everyone (transitively) depending on libc crate for FFI. The proper resolution is still in under way [1]. [1] https://internals.rust-lang.org/t/solve-std-os-raw-c-void/3268 https://internals.rust-lang.org/t/solve-std-os-raw-c-void/32...

llogiq 10y ago

This percentage includes people using explicitly unstable things (e.g. me).