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.
-
Increment the minor version as the development starts, leading to the eventual released software being probably something like 1.1.5562.12589
-
Keep the version at 1.0.x.x during development, leading to the
testedversion being something like 1.0.5562.12589 and then when I need to update theversionof 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.
7
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.
3
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.
2