6

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?

EDIT:

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 1.1.0.0 which to the customer or developer, may look like work has been done post a 1.1.0.0 release, such as bug fixes.

Option 2.
Pros - The version doesn't reach 1.1.0.0 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 1.1.0.0 version.
Cons - The version has to be manually adjusted from 1.0.x.x to 1.1.0.0 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 Apr 8 '15 at 9:55
  • possible duplicate of What is your application versioning strategy? – gnat Apr 8 '15 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? – Kilian Foth Apr 8 '15 at 9:56
  • @jonrsharpe I've added the pros and cons as I see them. – dougajmcdonald Apr 8 '15 at 10:11
  • 2
    If you don't want to confuse the end users, why not just tell them major.minor? – jonrsharpe Apr 8 '15 at 10:16
6

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 3.2.4.1234 - marketing and development are very different things. – gbjbaanb Apr 8 '15 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. – dougajmcdonald Apr 8 '15 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. – Jörg W Mittag Apr 8 '15 at 13:49
2

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 Apr 8 '15 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 Jun 14 '18 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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