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.
Ah, OK, we're in agreement then :)
Re:Go += Package Versioning
by woolvalley on Tuesday February 20, 2018 @04:32PM
(#16424393)
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.
Re:Go += Package Versioning
by dragonwriter on Tuesday February 20, 2018 @04:49PM
(#16424542)
> 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.)
Re:Go += Package Versioning
by steveklabnik on Tuesday February 20, 2018 @05:13PM
(#16424733)
Yup, elm pioneered this space. We're giving it a shot too https://github.com/rust-lang-nursery/rust-semverver
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.