Version numbers and project names
Many product managers are familiar with rules and strategies for product naming, but what about version numbers and project code names? Do we need them? Who owns them?
Product version numbers are primarily internal tracking numbers used by technical support, development, and QA. I've spent many hours on technical support calls and surely one of the first questions one asks is 'what version are you running?' Perhaps the easiest call to take is one where the problem occurring in version 1.1 is solved in version 1.2. The support rep just says, 'Yes, that bug was corrected in version 1.2. Please upgrade.'
Product version numbers typically consist of three fields: the major version, the minor version, and the update version.
X: major release with identifiable new features
Y: minor release with existing feature improvements
Z: update release (distributed) containing bug fixes but no new functionality
There is often a fourth number associated to the code build. Not all builds are distributed but this number generally represents a count of builds from the beginning of the development project.
So 188.8.131.5221 means
9: Major release of functionality
0: no minor releases yet
1: bug fix released to public
3821: development build
These program version numbers need not necessarily correspond to the numbers used in our marketing, as we see with Microsoft products. Word 2000 (communicated to the public) is really Word 184.108.40.20621 (internal to the product team). Product marketing owns the name that's distributed; Development owns versioning and the project code name.
Numbering schemes are largely irrelevant to customers; versioning is only for keeping track of what is shipping to the customer. There are many software developers who think that numbering schemes are a not-important marketing aspect of the product. Marketing people and customers generally do not (or should not) care about version numbers.
What should we tell the public?
In most cases, a change in the Major version justifies a product launch with a press release or some communication in the market. Some companies use the major number to require companies to pay for the upgrade rather than getting it free as part of the maintenance or subscription.
Minor upgrades are proactively communicated only to the customer base but not to the general public. They don't justify a formal launch beyond getting the company ready to support it.
Updates are communicated on the web site and from tech support. Power users will encounter the update information on the product support area of the web site and download it. The majority of customers need not know about it unless they encounter a problem fixed by the update.
Builds are never communicated outside the product team (development, QA, product management, and usually tech support).
- related article: What should we preannounce? Read Mouth Wide Shut on Joel on Software.
Project Code Names
Project code names are often assigned to a new project; these are also internal to the product team. Frankly, we recommend that project code names be silly or somewhat offensive. Use foods, diseases, or cartoon characters as the basis for code names. I doubt people will talk publicly about the 'Deputy Dawg' release or 'Taco' or 'Ear Wax.' Otherwise, some names seem so clever that we start using them outside the team, and pretty soon the channel knows and then the customers knows. Before long we start getting calls about the status of the 'Nile' release. And when we decide the actual product name, everyone has already gotten used to calling it 'Picasso' and it's much harder to get the real name accepted.
Using Versioning with Goals
In Requirements That Work (now called Build), we teach a technique for using goals to define sets of functionality for release. Goals help us achieve a ship date with a product release that offers a complete using experience. Versioning can help here as well, with one modification. Since we group the product requirements by user goals, we can use the version number to define target sets of functionality. We'll use the 'bug fix' for release candidate.
Let's say we're doing a new major upgrade, planned to be v2.0. The new release has a new data model and other architectural design changes. When these changes are complete, we can extend our 3-D modeling capabilities in four functionality areas. If we can complete it by the end of the year, we'd also like to offer a new set of statistical functions specifically designed for business planning that allow the customer to calculate time value of money as well as NPV (net present value) and EVA (economic value add). Using goals with versioning we can plan:
V2.0.0 = architectural changes
V2.0.1 = 3D modeling
V2.0.2 = business planning suite
After completing version v2.0.0 we can begin the functionality for v2.0.1. After that goal is complete we can begin v.2.0.2. What if we realize we need to ship before v2.0.2 is ready? Just release v2.0.1--the last set of completed customer functionality--as 2.0 and then continue developing v2.0.2. When completed, we can release this functionality as an update, as Microsoft often does with service packs, or as release 2.1. In this case, the 'bug fix' node is serving double duty: as release candidate on prerelease product, and then as bug fix for released products.
Version control is a required element of mature product planning, largely an internal method of tracking. Version numbers catalog which features and fixes are available in different distributed versions of the product. Versioning can also be used to accommodate goal-oriented product planning, as taught in Requirements That Work. Project names are merely shorthand for specific development projects and should always be kept internal to the company. The nomenclature doesn't really matter as much as an understanding of what version numbers and project names mean to your product team and its customers.
Additional thoughts (in 2008):
I have seen four themes for naming releases:
name (or model number without any version numbers)(salesforce, Linksys WRT54GL)
name + year (Office 2007, iLife 08)
name + version number (iTunes 7.3)
name + release theme (remember OS/2 Warp?)
Hosted services tend to have no visible version number although there is always a version number somewhere for tech support purposes. Obviously, Microsoft has gone with the year method and there's something great about that: You know that you're really out of date if you're running Office 2000. The negative is if the vendor hasn't delivered anything since 2000.
In the end, I think the naming standard depends on what you're trying to accomplish. A major release usually means that you charge the customer for it. I actually am annoyed when I'm charged for a minor release. I just upgraded from a product's 7.1 to 7.3 and had to pay $75. I'd be more willing to pay to go from 7.x to 8.x--which is the most common situation. But at version 12 and 13, this starts to get a little ridiculous. Version numbers become less relevant as the product reaches maturity.
I suspect that your customers do not care except as the name or version relates to billing.
Looking for the latest in product management news, articles, webinars, podcasts and more?