Traditionally software build numbers fit into the formatMajorMinorReleaseBuildWhere a Major version is implemented whenever there are breaking changes, Minor when new mini features are added, Release when something is published and Build each time it's built.I find the last two digits work really well in a CI environment, each CI build increases the Build number and each release to live increments the Release number.However major waterfall work and breaking change developments are discouraged in more modern methodologies. We prefer to release little and often and so don't tend to make great breaking changes. Given this it's very difficult to determine when to create a new Major version.We try to avoid making major breaking changes and so are getting very high minor/release numbers but haven't had the excuse to move up a major version yet. What criteria should be used to determine when Major and Minor builds should be made (particularly web based applications)?I'm aware there are date style versioning but I'm interested in the Major.Minor.Build.Release only.
Controlling version numbers in sprints
agile;versioning
I think some of the challenge starts with your assertion of:Where a Major version is implemented whenever there are breaking changesAnd 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 differentThey ought to prepare or be aware that this likely won't be a trivial updateSo 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.