5 ms·

> There's a middle ground which includes security updates: asking the community to follow semver. No, that doesn't work. People make mistakes, and you end up n

> There's a middle ground which includes security updates: asking the community to follow semver. No, that doesn't work. People make mistakes, and you end up not being able to build software. It might work _most_ of the time, but when things break, it's of course always at the worst possible time. I think Cargo got it right: use semver, but also have lock files, so you can build with _exactly_ the same dependencies later.

kodablah 9y ago
Sorry for the confusion, but that's what I meant. I was addressing the use-exact-versions-all-the-time argument. Maven goes too far in that it is taboo to do anything but use specific versions. Cargo, composer, etc do follow the proper approach. Maven w/ version numbers like "[1.2,1.3)" shouldn't be so taboo IMO. The "commit lock files for apps and don't for libs" is also practical.
- wtetzner 9y ago
  Ah, OK, we're in agreement then :)
woolvalley 9y ago
With strong typing, you can analyze the code and automatically increment the semver versions based on public API changes. Elm does this AFAIK. Reduces the amount of mistakes that are possible.
- dragonwriter 9y ago
  > With strong typing, you can analyze the code and automatically increment the semver versions based on public API changes. This is nice, but should be noted does not absolutely prevent missing backward-incompatible changes; that a function has the same signature does not mean that it has backward compatible behavior. (With a rich enough strong, static type system, used well to start with, you might hope that all meaningful behavior changes would manifest as type changes as well, but I don't think its clear that that would actually be the case even in a perfect world, and in any case, its unlikely to be the case in real use even if it would be in the ideal case.)
- steveklabnik 9y ago
  Yup, elm pioneered this space. We're giving it a shot too https://github.com/rust-lang-nursery/rust-semverver https://github.com/rust-lang-nursery/rust-semverver

kodablah 9y ago

Sorry for the confusion, but that's what I meant. I was addressing the use-exact-versions-all-the-time argument. Maven goes too far in that it is taboo to do anything but use specific versions. Cargo, composer, etc do follow the proper approach. Maven w/ version numbers like "[1.2,1.3)" shouldn't be so taboo IMO. The "commit lock files for apps and don't for libs" is also practical.

wtetzner 9y ago
Ah, OK, we're in agreement then :)

woolvalley 9y ago

With strong typing, you can analyze the code and automatically increment the semver versions based on public API changes. Elm does this AFAIK. Reduces the amount of mistakes that are possible.

dragonwriter 9y ago
> With strong typing, you can analyze the code and automatically increment the semver versions based on public API changes. This is nice, but should be noted does not absolutely prevent missing backward-incompatible changes; that a function has the same signature does not mean that it has backward compatible behavior. (With a rich enough strong, static type system, used well to start with, you might hope that all meaningful behavior changes would manifest as type changes as well, but I don't think its clear that that would actually be the case even in a perfect world, and in any case, its unlikely to be the case in real use even if it would be in the ideal case.)
steveklabnik 9y ago
Yup, elm pioneered this space. We're giving it a shot too https://github.com/rust-lang-nursery/rust-semverver https://github.com/rust-lang-nursery/rust-semverver