I think some of the challenge starts with your assertion of:
Where a Major version is implemented whenever there are breaking changes
And I'm pretty sure you mean "breaking changes" in the sense of significant API changes; client / server communication changes; protocol work, etc. "Big Stuff" (TM) in other words.
But the problem is that it's not just breaking changes that count but any significant change that counts. "Significant" varies from application to application, which is why it's hard to be specific about what qualifies as significant. Changing the major number should be an informal announcement to the end users that:
- Something big is different
- They ought to prepare or be aware that this likely won't be a trivial update
So here are a number of common reasons I have seen to update the major number:
- Marketing (or development) felt like it.
- Wicked cool, brand-new, big feature introduced. Or a whole bunch of these.
- Database schema underwent significant change. Oftentimes this will force an update for the end-users.
- Protocol changes. This can included significant changes between the browser and the web server, or could be between the client and server.
- Application stability has significantly improved (or worsened) and you want to change Major version to inform or warn users of the change.
- Some specific amount of time has passed - this could be X months, years, whatever.
- The product is now compliant with some external standard or otherwise audit-able process.
- The application was forked.
- Significant changes were made in supporting libraries, or which libraries could be used.
Generally speaking, you want to be able to say why you incremented the major value. This is where building an "elevator pitch" to justify the increment can be handy. And just like an elevator pitch that you use to sell yourself, this is a quick statement that summarizes what was big enough to merit the change.
Some additional thoughts regarding versioning...
First off, you don't have to update the Major value on a regular basis. It may not make sense if everything that's being provided is a lot of little items.
If you feel like you're "running out of room" with the values for the other numbers, consider:
- Use hexadecimal values (base 16) or another base instead of just decimal values (base 10).
- Use two or more digits within each value. So you'd have
M.mm.rr.bbb for example.