I have what I believe is a largely subjective question, but I'm interested in how people handle the situation described below. There are many similar questions on programmer stack exchange but none which touch on this precise issue of whether to update a version number to the proposed release before or after the development (that I could find).

I have a system which is live, lets call it version 1.0.x.x I'm using Major.Minor.Build.Revision Microsoft style versioning.

I get a customer request for some new features, and we decide that this package of work will be the 1.1.x.x release.

When would you update your version number, in development? As you begin work? or as you finish it?

I can see two approaches, neither of which I'm 100% happy with.

  1. Increment the minor version as the development starts, leading to the eventual released software being probably something like 1.1.5562.12589

  2. Keep the version at 1.0.x.x during development, leading to the tested version being something like 1.0.5562.12589 and then when I need to update the version of the assembly (which we'd do manually for a major or minor release) to 1.1.x.x strictly speaking that version of the code (as I'd have to had rebuilt it to increment the assembly number) hasn't been tested.

What's the preferred approach here?


In terms of pros and cons:

Option 1.
Pros - The version which is released is already 1.1.x.x so the minor number is accurate, and that build/revision represent tested code
Cons - The released version won't be version which to the customer or developer, may look like work has been done post a release, such as bug fixes.

Option 2.
Pros - The version doesn't reach until the development is complete & tested. Meaning there is a clean logical cutoff between work being made on the stable 1.0.x.x version and the deployment of the tested version.
Cons - The version has to be manually adjusted from 1.0.x.x to somewhere after testing but before release. Potentially including untested code if someone has mistakenly checked in the wrong area.

At the moment I'm not sure which is the lesser of two evils as I can see pros to both, as well as cons to both. I'm hoping someone might help me tip the balance or spot something I've missed.

  • 1
    You say you aren't happy with either approach you've identified - why? What do you see as the pros and cons?
    – jonrsharpe
    Commented Apr 8, 2015 at 9:55
  • possible duplicate of What is your application versioning strategy?
    – gnat
    Commented Apr 8, 2015 at 9:55
  • What, precisely, is your issue with option 1)? If you plan to publish something in version 1.1.X.X, then by definition you don't care what the X values will be. Why do you suddenly care again? Commented Apr 8, 2015 at 9:56
  • @jonrsharpe I've added the pros and cons as I see them. Commented Apr 8, 2015 at 10:11
  • 2
    If you don't want to confuse the end users, why not just tell them major.minor?
    – jonrsharpe
    Commented Apr 8, 2015 at 10:16

2 Answers 2


If your issue is that the customer might think 1.1.2475.54387 means "something has changed after 1.1" - forget it. In my experience, virtually all customers either don't care what the lower-order components in a version mean, or they do care and understand that they are build numbers and VC revisions, which by definition can never be 0.

Slightly more general: Looking good is a valid goal, but in a business context it only matters what the person who makes the purchase decision thinks. Those people almost always fall squarely into category (a) above. I can think of no scenario where having a non-pristine build number would negatively affect the business success of a product.

  • 2
    and many releases just tell you the first 2 numbers anyway, this is "product release 3.2" whereas the actual version is - marketing and development are very different things.
    – gbjbaanb
    Commented Apr 8, 2015 at 10:48
  • Thanks for the response, I can see the benefit in incrementing the version number to the minor number the system is 'going to be', rather than 'is currently', seems a sensible approach. Commented Apr 8, 2015 at 11:24
  • 1
    Marketing and engineering version numbers don't have to match. I hear there's this one company which has marketing versions like "2000" (corresponding engineering version: 5.0), "XP" (5.1), "2003" (5.2), "Vista" and "2008" (6.0), "2008 R2" and "7" (6.1, interestingly), "2012" and "8" (6.2), "8.1" (6.3), "10" (originally 6.4, now 10.0). The Windows 7 part is particularly interesting: they originally had used 7.0, but found out that this broke a lot of software that tested for major == 6 to figure out whether it was running on XP or Vista, and thus ran with reduced features on 7. Commented Apr 8, 2015 at 13:49

One big advantage of option 1 is that as soon as your software passes all the unit tests and acceptance tests against the new set of requirements, you can ship it.

If you delay incrementing the version number, then you will have to do another build with the correct version you want to ship. Having re-built it all, you really should re-do all the tests again.

  • You should be able to verify by inspection (of the final image) that changing the version number (post test) changes nothing else.
    – Andrew
    Commented Apr 8, 2015 at 12:25
  • @Andrew How? Diff? That would work under some circumstances, but in others (such as a jar or war file), changing the version, or even the simple time of compilation, alters the byte stream and subsequently compression etc., potentially yielding a file that appears entirely different than the first.
    – Erhannis
    Commented Jun 14, 2018 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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