I work for a company which uses Version-Oriented development. This means that we decide in advance which new features and enhancements to include in each planned version release. Hence, at any given time, most developers are working toward one specific version (with the occasional hot-fixes or patches for past versions).
However, we have some customers who were promised a certain set of features, which we would like to deliver as soon as possible without having to wait for a formal version release. How do we develop them, and how do we release them?
Surprisingly, one of the toughest problem is “how to name such versions?”. Do our SCM tools support non-standard names? what version ID do we want to show the customer? will we be able to upgrade it to an “official” version in the future?
We recently implemented a simple, but effective solution for this issue. Up until now we used 2 numbers to represent our official versions (e.g. 5.0, 5.1). Now, we started using 4 numbers (e.g. 126.96.36.199). The idea is as follows:
- The first two numbers are for major releases, just as it was before.
- The third number represents a minor version – containing relatively small amount of new features or enhancements, and has a shorter release cycle.
- The fourth number is for feature-specific versions.
Admittedly, the fourth number may cause some confusion, since for example, 188.8.131.52 doesn’t necessarily contain the features from 184.108.40.206. But since each of them it targeted for a different customer, it shouldn’t be a problem. And we do know that both features will be included in the next minor release, 220.127.116.11.
One important thing is to record the customer to which a feature-specific version ID is assigned, in a visible way. Currently we do it via a shared document, but we will implement a better system in the future (such as using a Version Object in the change tracking tool, instead of simple text field).
So far the system works well. But as usual, there is always room for improvement…