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 dont 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?
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).
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.