Confusing Conventions

 

Over the years, I've seen various naming conventions for software versions, also known as release numbers. "v2", "7.0.4321", "11.3.5432a SR-3", "RTK0320-R5-32", "Chicago". What do these cryptic numbering schemes mean? Which convention should your organization adopt? And more importantly, why should you even care?

Who Cares?

When things are running smoothly, nobody cares. Having a "good" versioning scheme certainly doesn't add any functionality to the product, improve its quality or optimize software quality attributes. But when problems arise in the field, then everyone cares.

Imagine the two following scenarios:

1.       A customer currently has 3.0 installed. He notices that 3.1 is now available, so he goes ahead and upgrades his system. Once the upgrade is complete, he launches this "latest and greatest" release only to realize that it's not backward compatible. In other words, he can't manipulate the files that he had originally created with 3.0. Worse, there's no way to "downgrade" the release. Shouldn't 3.1 be backward compatible with 3.0?

2.       Your latest stable branch is "Chicago", and your development branch is "Boston". A bug is detected in "Detroit". The developer commits her fix to the "Detroit" branch, but doesn't port it to the more recent …

Please log in or sign up below to read the rest of the article.