SemVer Shouldn’t Mean More Breaking Changes
Tom Dale

Solid point, but Python is a poor example because it was hardly frequent—the more than 25-year old language has had three major versions, ever. As a language, it’s also a foundational consideration for an entire ecosystem, as opposed to selecting a library/API to integrate into a single project.

There’s also the question of why we care about being on the latest version? If you have a long-term maintenance project with a dependency that meets all of its existing requirements, there’s no intrinsic need to update it. Quality dependency management allows you to specify the version you desire, and only upgrade periodically, after an evaluation of any changes in requirements and the dependency itself.

All that said, I don’t know what happens in the world of JavaScript libraries—I see the other commenters alluding to Angular—so maybe this is a real problem in that space. In my current work project, we have one dependency pegged at a version from April 2015 (which we have lightly patched, too). In SemVer measure, we’re on 2.5.0 while current is v4.2.2 (and 5.0 is in alpha).

Good food for thought.

Show your support

Clapping shows how much you appreciated Oluseyi’s story.