Anchoring Software to Major Versions

In a SemVer world, major releases are those which contain incompatible API changes. We often see software projects anchor themselves to major versions for long periods of time, usually with the promise of stability.

We all know how frustrating it is to upgrade a package and run into tons of breaking changes. Many of us have kept outdated software in production for longer than we should just because it can be such a pain to update.

I've been thinking a lot about this lately in the context of open source projects*, and I've come to believe that anchoring to major versions is counterintuitive. It's harder for developers, who have to maintain each distinct version for long periods of time; it's worse for consumers, who eventually get hit with a slew of broken things all at once; and it holds back features and improvements that can't be implemented until breaking changes are made.

Of course, there's something to be said about maintainer discipline. Are we breaking things for a good reason or just because? Do our changes actually benefit the project and its users, or does it just feel better to do it this way now? Every project is maintained differently.**

But the more I think about it, the less it makes sense.

For many projects, major versions should be released more frequently. Things are easier to maintain when the path to upgrading involves less friction; consumers are more apt to retain familiarity with less time in between updates; and developers can stop being scared to do the right thing for fear of a major version bump.

The right kind of breaking changes are good. We should embrace them rather than avoid them.