A version by any other name

by Amir Shevat

“A rose by any other name would smell as sweet”

Shakespeare's Romeo and Juliet

Product versioning is a matter that lies in the grey area between marketing and R&D. Lets take Java for example (I like Java that is why I use it as an example). On one hand marketing people think that calling a product “5.0 code name Tiger” would be much better than calling it 1.5 (and don’t even think about something like 1.5.0_04-b05). On the other hand, R&D people, though really fond of Tigers, would prefer to see “1.5.0_04-b05” as the version name. This version name provides R&D with the information they require such as the knowledge that a certain bug was fixed in this version. I think that is why SUN markets JAVA as “J2SE 5.0 tiger” but when I run “java –version” on my computer I get “java version 1.5.0_04-b05”.

Another issue with product versioning is the correlation of version numbers between tightly coupled products. I will take our open-source project for example. Our main open-source product, MantaRay, is a JMS provider that comes in 3 different flavors – a pure java implementation, a C++ wrapper over the java implementation and a pure C# implementation. In addition, there are several other components such as the MantaRay Management Console.

Up until the last release we use to give each component its own version number. However, the problem was that we started getting users’ feedback saying that they find this naming convention to be confusing. Every product came with a read-me file that stated the compatibility with the other products’ versions. As a result, we had to deal with bugs that originated from people running incompatible versions of the different products. Moreover, our marketing people did not like the fact that we distribute three different JMS products with different version numbers. They wanted to market a single solution with three flavors.

In order to amend these problems we consolidated all of our sub-products under one version called MantaRay 1.9, we hope this will be less confusing and will generate less product-interoperability errors. I guess you could look at this decision as both marketing and R&D driven.

The bottom line is that a version by any other name would smell as sweet..

Is product versioning an R&D decision or a marketing one?


2006-01-26 13:39:37
Matthew, Matt, or Dr. Matthew B. Doar?
Just as we all have different names in different situations, there are version strings for marketing, versions for use by support, and versions for developers and testers (possibly the same as the one for support).

I discuss a scheme called "complex numbering" in my book "Practical Development Environments". Just as a complex number has real and imaginary parts, a version has a build label such as "myproject build 23" and another marketing-related name such as "CoolProduct 1.2". The two can be orthagonal.


2006-02-09 14:42:07
Versioning is no different then any other project artifact
Any project artifact needs to have clearly stated audiences and for different audiences we may have different views. So versioning don't differ in any way from any other project artifact.

Versioning is to help users communicate without ambiguity. There are two major stake holders to any software - the developers and the end users. Management also falls under the end user for all practical purposes.

Developers intention while versioning any product is to be able to track any changes easily and be able to quickly with least references to piles of document say oh version X, it will or will not have this bug. Or bug nnn has been fixed in version X.mmm where mmm > nnn.

Whereas when end users see the software version they just use it as name or use it to know the chronology. So as long it satisfies the uniqueness criteria and does not confuse about order it should be ok. So never do 1.2 release after 1.3 and users will be happy to use the simple version. I personally tend to dislike codenames because they dont give you any idea what is the ordering.

So yes have two version numbers - external and internal.