SemVer has failed us

Post by bhaak » Sat, Aug 09, 2014, 8:03 AM UTC

dustingetz wrote: post #49

bhaak wrote: post #24

Earlier quoted context omitted.

Huh? Which ecosystem advocates automatic updates and doesn't allow locking the version numbers of the dependencies until a developer manually updates them?

This particular example is javascript/Bower. A fresh clone and build of any javascript project using Bower has a non-deterministic build if it uses Bower's semver capabilites.

Yes, I read up on it. That's quite insane that there is no automatic way of having the exact versions required when installing something with bower.

Of course there will be lots of pain, it just takes one package to slightly violate SemVer and you'll have to hunt down the culprit.

What surprises me is that in the article they seem to think that switching to another versioning scheme will help with this problem. Especially as better tools would mitigate most of this problem.

Post by substack » Sat, Aug 09, 2014, 9:53 PM UTC

AaronFriel wrote: post #16

arohner wrote: post #5

Completely agree. For a long time, I've thought that humans shouldn't be in charge of version numbers at all. The main problem is that a human isn't reliable at determining "is this change breaking?". Unfortunately our software isn't well-specified enough to allow the computer to determine version numbers automatically yet. To make this a reality, you'd need Haskell-level type safety, along with specifying other cons…

For anyone in the Haskell world, it's obvious that semantic versioning[1] doesn't work. Some non-trivial amount of that is likely due to how horribly broken Cabal is, a problem the community remains in staunch denial of. But for the rest, one problem is that because Haskell more thoroughly specifies types, individual functions can remain the same in behavior but change in type because a bug-fix, say, fixes a record t…

> If we really want to move into The Future, we need to start > versioning individual modules or functions, instead of > whole suites of software. But the cognitive burden of doing > this is very high, and the software to do it hasn't been > written yet.

I don't think this problem is related to any cognitive burden, but is an artifact of how the package manager works and how easy it is to liberally publish packages. Consider npm, where people publish packages with little to no coordination and everything is mostly fine (whatever the author of the parent article says). Because it's so easy to make an npm account (anybody can `npm adduser` and start publishing immediately) and so easy to publish (just pick an unused name, make a package.json, and `npm publish`), people routinely make very granular packages, often just a single function. Importantly, these functions don't need to fit into a taxonomy namespace like in haskell which prevents namespace hierarchy turf wars for the lesser price of namespace landgrabs.

Better still, you can have multiple different versions of a library in the same application. In your example, libB would just get the version of libA that its constraints satisfy but elsewhere other libraries could depend on a version of libA that do not satisfy the constraints on libA that libB requires because every package gets their own copy of their dependencies, with automatic deduping when the constraints are satisfied to save space.

Re: SemVer has failed us

Re: SemVer has failed us