elm-package

A lot of people are commenting that SemVer doesn't work, because it's still at the mercy of humans choosing good version numbers. Elm's package manager, elm-package, actually tries to remove humans from the equation, by automatically choosing the next version number, based on a diff of the API and the exported types of a package: https://github.com/elm-lang/elm-package#publishing-updates It's not perfect, but it's better than anything else I've seen.

> try configuring maven vs npm vs Cargo (Rust) - http://doc.crates.io/build-script.html (simplicity) vs elm-package (Elm) - https://github.com/elm-lang/elm-package (automatic semver compliance) vs Stack (Haskell) - https://docs.haskellstack.org/en/stable/GUIDE/ with stackage-sets (packages tested to work well together) - https://www.stackage.org/

Elm has automatic semantic versioning based on the type system: https://github.com/elm-lang/elm-package/blob/master/README.m...

I want to see an 'algebra' approach to packaging -- strongly-typed packaging modeled as types and operators. Package and import systems present a lot of surprising behaviors and edge cases in part because they're not well-defined enough to be well-documented. Also, packaging systems need to get better at integrating with VCS versioning. The elm packaging system goes beyond this to automatically bump versions when your api changes https://github.com/elm-lang/elm-package#version-rules, whoa cool. But at minimum, make a note of git/hg id. The 'just use npm' approach is interesting too http://dominictarr.com/post/25516279897/why-you-should-never.... NPM's approach to 'dependencies of dependencies' has a lot of fans. Finally: part of the problem here is that there's no package manager for C. The author dances around this in saying 'C extension