As we start the New Year and coincidentally approach a major release of our Lexis Visualfiles product, my thoughts turn to planning our delivery schedule and the year ahead.
As we start the New Year and coincidentally approach a major release of our Lexis Visualfiles product, my thoughts turn to planning our delivery schedule and the year ahead. So, what version number should we assign our future releases and how might that be received by the community?
Over the last 20 years, our software has used many different version number formats, starting with a complex four point system. Currently we use a more conservative three point system indicating major.minor.patch levels.
An external facing version number has three roles to perform:
- To identify the code in use for support and maintenance purposes. For low level investigations, we can retrieve the full set of source code in use – in fact, our source control systems allow us to retrieve and rebuild any of our product releases over those 20 years.
- Determine whether one release is older or newer than another.
- Increase product awareness. A significant version number change supported by a marketing campaign can significantly increase awareness.
This all sounds easy - increase the patch number for a small set of bug fixes, the minor number for basic enhancements and the major number for something more significant.
Unfortunately, there is a perception that upgrading to a new release with even a small version number increment is a sizeable and risky project. Worse, it can lead to an approach of “I hear another release is due shortly, let’s wait for that instead” and before you know it, systems fall years behind.
So should we remove version numbers?
To try find an answer, I spent time looking at the naming conventions Microsoft adopted for its Windows Operating System. My experience of Windows started with versions 3.0, 3.1 and 3.11 before it switched to a series of names – 95, 98, XP and Vista – then back to numbers with 7, 8 and now 10. Interestingly, those v3 releases had matching external and internal numbers, but did you know Windows 7 is version 6.1, Windows 8.0 is version 6.2, Windows 8.1 is version 6.3 and Windows 10 has brought things back into line as version 10.0.?
Apple has taken a different approach for OS X. It has used names for all its OS X releases and internal version numbers starting 10 (hence the X in OS X). I like the use of obscure names and even as an infrequent user of OS X, I'm more familiar with Mavericks, Yosemite and El Capitan than I am version 10.9, 10.10 and 10.11.
Google has taken a similar approach of assigning Android releases a name with little significance, but unlike Apple, maintains alphabetic order and a consistent (confectionary) theme – Cupcake, Donut through to Lollipop and currently Marshmallow. A bit of fun perhaps, but for me consistency works.
Returning to Visualfiles, can I learn anything from this?
Yes. Users of Lexis Visualfiles will be aware of its recent User Interface (UI) rewrite, launched as “Visualfiles 2014”. There have since been further releases under the 2014 theme, our aim being to divert attention away from internal v3.0, v3.1, v3.2 and v3.3 numbers. It certainly helped us promote the product and launch the new UI.
Personally, an external facing convention using consistent names unrelated to dates or numbers seems to work best, reducing the perception of big jumps between releases. Who knows, maybe our next releases could be based on colours: Visualfiles Amber, Visualfiles Blue, and Visualfiles Cyan. Can anyone think of a colour beginning D?