Software version numbers seem like a trivial subject, not worthy of serious consideration or debate. It seems obvious enough — when you release new stuff the numbers go up, right? What is there to talk about?But version numbers are important. They are an interface as important as any specification, protocol or library. They communicate implications to your customers, your clients, your users and tell them what to expect.
Software versions are, in business terms, actionable data, indicating magnitude of change and thus approximate risk/rewards.
Based on this information I can make a choice if I want to update, and how and when to do so to mitigate risk. A stable and sensible roadmap allows your customers, managers and developers to plan.
How Software Version Numbers WorkSoftware version numbers are typically composed of 3 components: major, minor and point release, in the form x.y.z.
- 1.0 is a major version
- 1.1 is a minor update from 1.0
- 1.1.1 is a point release from 1.1
Software Version Number Components and Their Meaning
|Reward||Major improvements that warrant potentially incompatible external interfaces||Feature improvement/addition to internal components||Bug fixes — removal/reduction of crashes, regressions or potential security threats. Otherwise, it can wait.|
|Risk||Everything can break. Migration/update may be costly and require outside expertise.||Minimal||Minimal|
|Implications of Not Updating||Eventual loss of commercial support||Potential loss of performance/feature improvements||Immediate/existing instability and/or security risk|
|Approximate Decision Timeframe||Annual||Quarterly||Weekly|
|Incompatibility||Acceptable (migration)||Not acceptable||Not acceptable|
|Money||Commercial software re-licensing and support changes expected||No, existing licensing and support should not change||No|
|Training||Administrator and user training expected to some degree.||Maybe some for administrators re: configuration||No|
Far be it for me to dictate terms to software developers, there are many software versioning schemes out there; the important thing to realize is that the practical ones all account for a realistic software release cycle, which in turn accounts for decision-making within imperfect organizations composed of imperfect people.
And a lot of respectable real-world products indeed follow this pattern or something like it. But not all...