In my current team (actually the whole company) we end up within the dependency hell day by day. Not only that many teams just don’t do any versioning, if they do there are no clear rules how they should do.
Semantik Versioning specificationprovides a great introduction of how and when to use (semantic) versioning. Definitely worth a read.
In the world of software management there exists a dreaded place called “dependency hell.” The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.
In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.