Growth rings

Dedicated to Bart :)

First time I saw growth rings of the tree I have been told that they reflects its age. Each year the new ring is appearing so, you can easily calculate how long this tree stands there. As simple as that, life of an any software product could be traced by its version numbers. Just unlike the tree, the software has multiple branches of "growth" (or evolution): functional, maturity and so on. Actually every company has its own versioning approach, different identification of stages. But versioning is always incremental and usually do not require more then 3 numbers.

Before an any word, let me note that everything has a sense. The things like a "corporate standard" or something like that with lack of sense, are not argument here. Yes, people are irrational by nature and often hurt themselves, but that is rather exceptional than natural. At least I wish believe in that.

The version numbers, by idea, should reflect the product evolution. For this purposes the 1 number is pretty match. But the evolution, by nature, can reflects different aspects. Just from a business perspective we may tell about: a) adding new features and b) urgent patches. So far, we have 2 numbers.

An any software product has a name, that sometime become a recognized brand. Eventually, new technologies accomplish radical changes in product. Functionally it stays the same, but its API or how it organized internally is changed. So, we can say, that would be almost a new product. (And very often it really stored in different repository, has separate issue management so on so far.) But, business may want to preserve the brand name. Here we can go with the 3rd number.

So, for a version identification we require 3 numbers:

• 1st number reflects the product architecture (major changes),
• 2nd - new functionality (minor changes) and
• 3rd - bugs fixes (patches).

Oh yes, sporadically, a customer may request features that you do not wish to include in trunk at this moment. Or, unfortunately, there were discovered bugs, fixes of those may impact on other existing customers. With long lived products I can observe that pretty often. In such circumstances there is need to stick with particular release, but with its own incremental patches cycle. However, such product splitting is rather exception and unlikely in any company due complicated an issue and source control management. Really, in short term multiple branches is OK, but in long run there is sense to split such branches as separate products with its own source and requirements management or… just merge them. In other words, that additional number may be introduced for a while changes requested for that particular customer would be included in trunk or would spun off in a new product.

That’s it? Not really, because we lost the testing. That the part of product lifecycle the business rarely cares about and may vary in different companies. Each iteration produces build with certain identifier, just for reference (in issue, if any). Those identifiers may have specific symbols instead of numbers, or timestamps or whatever else I even can't imagine. But if somebody said that their testing process has a something unique and is not just an iterative process of localizing and fixing found bugs, he tried to sell you something. Usually, testing iterations are very short, so far doesn't required any source tagging. Really, which sense to tag the buggy or non finished functional? (If you going argue about this, I would say you trying to sell me something.) But you still need identify an each build, at least for reference. The thought is not a new, as I said, different companies used different approaches. And that is really wide variety: from the timestamps, up to an additional number (or symbol) in version, often called build (or drop). Really, a lot options, but any of them doesn't exposed to customer, so never become a part of product version.

You may argue, that each build shipped for a testing, is a release candidate. Yes, of course, it suppose to be once it tested. But why you have to ship to customer exactly the same bundle that was used for testing? Any build is built from source, yes? If you can produce different products from the same sources on different runs, I would say it something wrong with your build system. Yes, the testing stage may take a time. For some projects testing time may be comparable to development even. I would say, it is huge, multi component system, where each component has its own lifecycle so... has its own testing and releasing process.