View Full Version : Version Numbering, how do YOU do it

11-14-2005, 08:09 PM
I've just gone through yet another iteration of the version number discussion with one of our product managers. We have a product already released, for quite some time, with a version of FOO 1.6, the last release of which, SP4, has version 1.6.4.. I'm getting ready for a new SP5 release of this product, with the additional constraint that we'll be issuing Quick Patches against SP5 until the next SP release. SO, what is the best way to assign version numbers?

1.6.5 would match the product's marketing version FOO 1.6 SP5, but leaves no way to patch without confusing Major Upgrades (the SPx releases) with patches. Specifically, if a customer has patch 1.6.14 in hand, how do they know which base release it applies to?

1.7.0 would then leave the least significant number for patch numbers, and it becomes trivial to know that 1.7.14 is a patch that applies to release 1.7.0. BUT, this implies a significant product revision.

Since customers can view this number, it seems to bridge the marketing and technology line. How do YOU handle this issue?

Christopher Painter
11-14-2005, 09:23 PM
Honestly, after 10 years of fighting this battle, I've given up.

The best reccomendation I've seen is to let program management handle major and minor and let development manage the build number.

11-15-2005, 05:56 PM
I am trying to understand the implications of "giving up". If you defer to Marketing, i.e. non-technical people, then the challenge is implementing the desired behaviors while using the version numbering scheme they've chosen. But, the version number behavior is deeply embedded into the install tools, so I don't quite follow how this can be accomplished?

Maybe I'm misunderstanding some of the behaviors within the installer tools?

Let's continue my example... I have FOO 1.6, the last release of which, SP5, has version 1.6.5 and I now need to patch it. Marketing wants the version of the product to stay at FOO 1.6 SP5, i.e. 1.6.5, yet my understanding is that the patch needs a bumped version number? What do I use here? If Marketing had their way, the version would be something like 1.6.5P1, but that doesn't fit the constraints, does it?

Christopher Painter
11-15-2005, 07:11 PM
Your correct, the logic is tightly coupled. Maybe I'm a bad example here, but honestly I've given up. I give advise to the powers that be on how the versioning should work and then I let them do whatever crazy thing they want. Eventually a problem creeps up, they come to me, I explain again why its a problem and I go about coming up with a workaround.

I know this may sound insane, but I've stopped trying to change the world. Marketing/Program Management will sometimes do things the way they want and no amount of lecturing from me is going to do anyone any good.

11-15-2005, 08:30 PM
I think I do understand your rationale after the last couple of days of this "discussion" by my customer.

So long as we are going down this road of expectations vs. reality, let me touch on one other such situation I have here. One important piece of background first. I work in the greater Redmond area, thus there is always a big shadow hanging over software related efforts. I have one person in qa who spent time working at the largest software producer in the greater Redmond area. They keep telling me that I should be able to do everything that they did there. I think he has formed the opinion that the only reason I can't do things as he describes is because I either don't have a clue, or I won't bother to figure it out. So, when I describe the version number issues, his response is ... yeah, well I'm sure its possible since they don't have this limitation over at M.....! Or, when I describe the limitations of patching, I get the same thing. Any installer limitation immediately gets the same response.

I'm looking for two things... first, reassurance that this view of the world, that since Microsoft can do it, surely I can too, is unrealistic. Sure, in the world of software I can do ANYTHING, given unlimited time and money. But, the business of producing software is to get things done within constraints, and Microsoft does not serve as a good model for a small company. And second, any advise you might have on managing this individual would be greatly appreciated. I know I need him in my corner and this issue is not doing that relationship any good.

Christopher Painter
11-15-2005, 09:29 PM
I wish I had something good to tell you. You know, customers are ALWAYS right. I had one customer that used this versioning format:



This was despite the fact that the requirments document stated that we were required to be DIICOE complaint ( US Military Integration Platform ) that specified an x.y.z format of major.minor.build where program management dictated major and minor and dev ( CM ) dictated build. You see instead of promising an external customer a certain release, they would promise a certain build. Then when the milestones were missed they would simply rebuild that "build" with multiple patchbuilds that were really full builds. It was a completly political decision. The client patch and server patch fields were added later when we needed to be able to do patch deployments but the functionals wanted to be able to look at a version number and know if there were client changes or server changes since the last release.

The way I can see it is you have 3 choices

1) Surf monster.com and go tell this QA person 'if you like Microsoft so much why don't you go back?"

2) Dredge up Microsoft white papers and standards and push your versioning idea as Microsofts idea ( Probably won't work because this person probably really thinks they are BETTER then Microsoft .... I know I am! ehehe )

3) Say Aye-Aye, Sir, get the versioning policy in writing and worry about the little bombshells later.

11-17-2005, 01:46 PM
Next problem...

Let's say the first version of the product is 1.0 (gee, that's a big stretch!). Now we want to ship a Major Upgrade, so they want to name it 1.0.1. But, that leaves no field for patch numbers, so I've lobbied for 1.1.0. 1.1.0 is unacceptable, because that implies its a major feature release (marketing speak). So, they want to go with 1.01.0. This is fine within the control panel, where 1.01.0 is displayed. BUT, we assign the same version to our assemblies, so looking at the file properties and examining the version shows 1.1.0, and people are having heart attacks up and down the halls.

I'm sure I know the answer, but I'll ask this anyway... is there a way to force the file property to show a version of 1.01.0, i.e. keeping the leading zero? If not, then we're going to ship this as 1.0.1 and patch versions will not be clear and obvious, but, to borrow your statement...


11-17-2005, 02:14 PM
Oh... I should mention, I also spent some time working with DIICOE. It had its own set of "challenges", though right now the product version/installer version battle seems to cast a much larger shadow.

11-17-2005, 02:15 PM
I have installed in mine schemes BDE 5,01, more I do not have the Delphi, in my project in the part redistributables does not appear BDE to select. My project demands that the BDE is installed therefore the EXE was compiled in dephi.

Christopher Painter
11-17-2005, 02:19 PM
Well technically Microsoft reccomends Major Upgrades to be full releases like going from 1.0.0 to 2.0.0 but in reality FindRelatedProducts will compare the first 3 fiends so going from 1.0.0 to 1.0.1 would work for a major upgrade. You could also say -> since MSI would ignore the 4th field. This field could be reserved for your patching.

Personally I don't even like patching unless your product is huge. I did enterprise engineering work and Administrators don't really want to be tracking down patches for products. Its much easier to say here is the latest version of the product and just push it. Major upgrades are nice this way. When using a tool like SMS to go touch free at 2am it doesn't really matter that its transactionally more expense.

So you know all about DII COE I&RTS segmentation..... sorry.

11-17-2005, 02:35 PM
A clarification... Will a Quick Patch work if the ONLY difference is in the 4th field? If so, then I might have a solution since that gives me slightly more room to work in, though right now we use that field for our automatically incrementing build number.

I also have run across the .NET assembly's AssemblyInformationalVersionAttribute, which seems to solve the leading zero problem. It seems to be a MUCH better way to display the version to the customer, though it would force a divergence from the Installer version, unless there is also a way to set the visible installer version (i.e. Control Panel/Add/Remove Software/"Support Information" version) such that its an arbitrary string rather than the actual, working, installer version?

Our strategy is to issue only Major Upgrades or Quick Patches. Thus, if a hotfix can be done in a Quick Patch, terrific, we issue a patch. If it can't, or its time for a "larger" release, then we go to Major Upgrade. And we will very definitely depend on the first three fields being significant when in comes to the way MSI actually works. People are having heart attacks in the hallways over loosing a leading zero in the second number, I can't imagine anyone would survive the thought of having to change the most significant field/number to issue a Major upgrade.

I'm not even going to go into the issue of who is actually the user of these installs.

(yeah, I spent time in the MITRE DII COE lab trying to figure out how to properly segment the large software system I was working on at that time)

12-22-2005, 07:14 AM
That's the way we do it in Greece ;)

We use 4 digits: Major.minor.sp.build. First two are controlled by marketing and changing them means a whole new installation. It means that a new installation CD is sent.

SP is controlled by the product manager --me :) . Our Internet Update system (developed in-house) patches the app, changing the version to, say, 4.2.1.

Build is controlled by the individual progammers . Once again, Internet Update patches the app.

So the last two digits mean a fix in the application. The difference, from the user's point of view, is that a Service Pack addresses serious problems and is therefore critical. Note that a SP also incerements the build number.

So in the last two years we had:

FOO 4.1 <- A CD is sent
FOO <- For marketing, 4.1 SP1
FOO <- For marketing, 4.1 SP2
FOO 4.2 <- A CD is sent (actual program version:
FOO <- For marketing, 4.2 SP1
FOO <- For marketing, this is still 4.2 SP1.