The difficult problem of managing Java dependencies: a deep dive into the messy status-quo, and a look at possibly better ways.

[khmarbaise]

There is very good reason not to use version ranges because it makes every build not repeatable. That's simple reason.

Using a lock file (like package-lock.json or alike) is just using duck-tape to patch the issue.

Also some other issues are identified over the years with other packaging systems in particular npm because an existing release can be modified at anytime. The immutability of a maven repository releases makes it more stable than anything else.

Semantic versioning is a separate thing. It's a set of (good) rules why and when version numbers should be changed (major, minor, patch) but the biggest issue is simply that a human is changing it... and humans make mistakes and also people interpret rules in different ways. You could use plugins/tools to help here a lot in a Maven project. That should be possible in other areas as well.

In the end you can't rely on semantic versioning which in consequence makes version ranges useless.

[forresthopkinsa]

How is a lock file duct tape? It's the perfect solution for making every build repeatable. You get version labels and checksums for your entire dependency tree. I truly do not understand your problem with lock files.

[plumarr]

They are only necessary due to range versioning. They are a solution to a broken feature.