One of the issues faced today by developers in this increasingly changing market is to not look like you are standing still. Many have decided to go to a rapid development style. While this can work out in very specific circumstances like cloud and web apps, this approach for traditional desktop programs has been very hit and miss on its effectiveness on stability and sustainability. However, we are not here (today) to talk broadly about the advantages or disadvantages of rapid development or even rapid release on desktop programs but merely a very specific aspect which has gotten way out of hand. Namely, versioning schemes.
To start out, we must establish this very important point when talking about version numbers. First and foremost, they are arbitrary. That is, there are no requirements to follow any particular scheme of versioning. Every development team must make that determination in relation to the project.
This seems to be where the older confusion comes into play. Versioning schemes originally were to help the developer keep tabs on the progress of their program. This had a support benefit as well, allowing users who had issues to identify to what particular incarnation of the program they were running to help narrow down changes to some aspect to a particular version. Soon after it seemed, our favorite department of any organization latched on to it as well. The Marketing Department (cue dramatic music and lightning).
Since we’re not going deep into how marketing works for software, we will stick to the surface points. As most already know or can guess, Marketing’s job is to market the program to a particular customer or user base. Marketing uses all sorts of tactics to demonstrate why its product is not only better than the competition but better than what it had already released before to justify the cost in monetary terms and/or time and resources to get the latest (and allegedly greatest) software. Naturally, one of the selling points is that ubiquitous version number either expressed in incrementing numbers, years/dates, or some whimsical sub-branding name (hello Windows Vista).
This, over a protracted period of time, has trained even the most hardcore computer geek to react to the knowledge of a new version out there as if it is very likely better than what is currently in use. However, such snap reactions can prove to not always be the case in reality.
In the past it wasn’t exactly easy to get new software. You had to go to your local computer shop or refer to your favorite computer catalog to get those shiny new bits. However, today we have the Internet. The Internet has allowed us to move away from fancy boxed software to digital downloads of anything we need. This was widely adopted by smaller companies and individual developers very quickly. However, the larger companies adopted this over a longer period of time and in stages. First by offering updates, but now you can even upgrade the entire software package (such as the entire office suite or operating system) to a new major version purely through some sort of digital download scheme.
The ability to distribute new bits to users so easily has begun to influence how software development is done. Unlike web app development (where software updates are instantly applied to all users at once), new releases of PC software historically could not be rapidly adopted. App Stores and other integrated online distribution schemes have enabled iterative development styles to be much more successfully applied to PC software.
While we are not trying to (today) comment on the effects of such rapid cycles can affect the actual state of a program from a code perspective, it is inevitable that it has to be touched on. The most seemingly popular method of depicting and differentiating versions is by incrementing numbers with two or more components (the major and minor version number, usually depicted as x.y). Most commonly, the major version number is bumped for programs that reach a particular significant milestone while the minor version number may be increased for smaller scale changes. As this is subjective to the specific software product, a version bump remains an arbitrary change from a user prospective without insight into how the project is managed.
Unfortunately, the tendency to either unintentionally or otherwise get into version wars does happen between competing products in the same category. This tends to reenforce the misguided perception that Product A version 4.78 is not as good as Product B version 7.0 strictly because it has a higher version number despite Product A having superior capabilities in many respects to Product B. As mentioned already, the marketing department wants to make its respective product seem better and we know it has used the version number as a vector to achieve this goal. When rapid release is thrown into the mix, the arbitrary and subjective nature of version numbers starts to increase exponentially (figuratively and literally) to the point where they are largely meaningless as a tracking and determination mechanism for everyone (even the developers of the product). One common example of this in action are web browsers.
For a specific example, Firefox is on a rapid release cycle dictated strictly by the calendar. This is relatively new for Mozilla (it was adopted in 2011). Mozilla has had questionable success with this approach. The decision to adopt this strategy appears to be in response to Google Chrome and its release methodology allowing it to reach version 36 at the time of this writing, despite only being six years old as a product.
Obviously from a marketing standpoint, this gives the perception that Chrome is very much ahead of the curve than Firefox or any other web browser. By adopting this strategy, Firefox was able to massively increase its version number and perceived worth all the way up to the 30s today (placing it nearly equivalent to Chrome in version numbers). Using the older versioning scheme with Firefox’s actual development, Firefox’s version number would probably be somewhere between 6 or 8. This causes some confusion to those with even a passing familiarity with what to expect in a major version of Firefox. The resolution of this confusion is very simple. The Firefox version number means absolutely nothing. The Firefox version number is bumped by the calendar. Unless there is a show stopping bug that prevents the code from compiling for the intended release date, it is version bumped and released. It is just that simple.
So what do we do when the version number is meaningless as an internal tracking method and irrelevant from a user perspective? We stop considering the version number to be any kind of indication of actual development. In regards to web browsers specifically, we stop trying to develop version assuming methods such as user agent detection that may prevent something that may report a specific version number. We should also break the tendency to compare and contrast products in the same category based on this meaningless number.
If you think the issues in this couldn’t get any worse, then consider that many products these days are mostly (if not completely) open-source. If a divergent project springs up and forks the code (from Mozilla, for example) and develops its own product, then one would tend to compare the two products with each other because of code and feature commonality. But as the two projects head in their respective directions for development and management, the code of the two projects increasingly diverges and it becomes necessary to stop directly comparing them as if they are the same. It is nearly as unproductive as doing so to products that share no common code ancestor. Especially if the project initially follows a versioning scheme closely in line with the original product and then later changes the scheme as the changes between them mount.
For instance, the Pale Moon project (which does not follow Mozilla’s rabid rapid release cycle) codebase is based on the Firefox ESR24 version. However, it has had significant code changes that are original, restorative, and back-ported from later Firefox versions and the once purely Mozilla codebase has become very distinctive over time. In terms of features, Pale Moon’s back-end codebase could be considered comparable to today’s Firefox back-end despite Pale Moon still using a 24.x version number. As for the front-end code, there is no comparison direct or otherwise in terms of code commonality anymore, due to Firefox’s switchover to Australis. This has resulted in a somewhat related but completely different products with different goals and target users. Version numbers do not indicate much, if anything, between the two or any other piece of software in the web browser category.
So when you see one product that increments its version number rather often and another in the same category that does not, do not jump to conclusions and fall into the trap of choosing one over the other because one jumps forty-eleven versions in a year and the other has only increase its minor version number by a few points.