Traditionally software build numbers fit into the format

  • Major
  • Minor
  • Release
  • Build

Where 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.

  • Seems like this is more of a sales and marketing issue. Do the developers lose track of significant changes?
    – JeffO
    Jul 1, 2014 at 13:22
  • @JeffO I suppose it is. 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!
    – Liath
    Jul 1, 2014 at 13:31
  • I don't think release or build being an incrementing number help anyone. Why don't you make them more meaningful? You could incorporate your sprint # and days/time since the beginning of the sprint. This would allow you to look at a version number and determine exactly when it was created. Jul 1, 2014 at 23:26

3 Answers 3


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...

  1. 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.

  2. 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.

If the user of your software is not able to update to the new version and use it without further manual migration steps (data, configuration, interfaces and the like), that is a strong indicator to increase the major version.

  • Would you apply the same logic to web apps? Config changes require a new major version?
    – Liath
    Jul 1, 2014 at 7:17
  • Configuration changes do not require a new version per se. If there is an automatic migration, I would argue, that a new major version is not needed.
    – Benni
    Jul 1, 2014 at 7:24
  • Ah, I thought you were using the config change as an indicator that sufficient code had changed to warrant a major version. No, I wouldn't suggest changing a version just because you've changed an email address!
    – Liath
    Jul 1, 2014 at 7:31

Whatever you're using internally, externally you're still going to have a waterfall like release cycle.
Whether it's now called a "feature release", "release to production", "customer delivery version", or whatever, it's going to be the combined product of a number of sprints and shorter internal cycles.

That's where the high level numbers come in.

So you'd have a number per nightly build (which might be overkill), a number per sprint, a number per delivery to sales/delivery, and then they put some nice marketing approved label/number on it that's often completely unrelated to anything used internally.

Not the answer you're looking for? Browse other questions tagged or ask your own question.