Semantic versioning is brilliant, but it won’t scale

Those who don’t understand Unix are condemned to reinvent it, poorly.
— Henry Spencer

UNIX never experienced the DLL hell, with a brilliant simple trick in library naming convention. This idea was so good, that it later got also formulated more articulately as semantic versioning, and huge ecosystems such as npm are built around that.

However, when you start applying semantic versioning to your interfaces, probably it will expose some of the weak points in the design. This will happen in the form of too many missing features so you have to increase the minor number too frequently, and worse many breaking changes bumping the major number. It’s always good to experience the moment of truth sooner, and you can start with 0-versions as a form of training wheels.

One of the underlying causes of the weakness could be that the interface is too big. As we know from the interface segregation principle from SOLID, smaller interfaces cut for specific clients’ needs are better. That’s why I find that semantic versioning is brilliant, but only for small, targeted interfaces; don’t push it to scale, or you’ll suffer from many breaking changes.

On the other hand, smaller interfaces mean inevitably a larger number of interfaces in total. This is per se a complexity, and if not handled properly it will propagate through the system up to the user, having impact not only on the development of higher layers, but even on UX. As a good example, I believe npm’s handling is quite elegant, so I’d like to highlight its major elements I find essential to its elegance:

  • Apply semantic versioning consequently and consistently
  • Specify only immediate dependencies, derive indirect dependencies
  • Solve the diamond dependency problem by allowing side-by-side installation of different versions
  • Also allow specification of implicit dependencies such as peer dependencies

These elements will allow you to specify a whole valid version set by specifying a small set of packages and their versions, while having to focus only on immediate dependencies.

This being said, this level of ease of reuse has exaggerated some risks inherent to software reuse, security being the most prominent of them. The recent study Small World with High Risks gives a very good overview of this problem, and also suggests some measures. npm also offers some tools such as npm audit, and also npm outdated; so I’d suggest you check these out.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.