Share This:

Happy New Year to all! Welcome to the roaring 20s even if we still don't have our flying cars.


Numbers are amazing things, but so ubiquitous that most of us probably don't think of them in any detail, unless you happen to be a number theorist. One of the first things we learn as a child is to distinguish one object from another, and then to give labels to different sizes of collections, and the ordering within them: the cardinals and ordinals. Then we learn the rationals, reals and the wonders of complex numbers and vectors at school. That covers what is needed for most of Science and Engineering, although you might use extensions like quaternions and tensors. In more advanced maths and theoretical physics you might encounter esoteric beasts, which I sometimes try to get my head around. My favourites are Cantor's transfinite numbers, the surreals, Grassmann anti-commuting numbers and p-adic numbers. As an aside, all natural numbers are provably interesting.


To try and drag myself back to a (more prosaic) point: numbers are also be used to version software. This is, of course, a fundamental way of keeping track of what set of features and defects are bundled up in a release, what the support status is - and perhaps what the state of stability or security is. Historically, most software I encountered used a Semantic Versioning scheme, for example three or four groups of digits, like:


  • [Major].[Minor].{Patch]


We currently use this scheme for Discovery; at the time of writing the latest on-premise version being (in our scheme the third digit group is always zero; this is patch 5 on major version 11, minor version 3). This scheme has advantages:


  • Major version of 0 indicates pre-release software that is not production-ready
  • Major version jumps indicate a large feature set uplift, and/or large architectural changes
  • A Patch release should only contain bug fixes, not new (or retired) features.
  • Compatibility, effort of upgrading and risk can be estimated: Usually it's reasonable to suppose the upgrade from 9.X to 10.0 is going to be longer/harder/more significant than, say, 10.0 to 10.1.


But even in this scheme, things are not that simple. The popular PuTTY client has been going for 20 years, and still on a version 0.X - and yet it's stable and commonly used in production. In relation to the last bullet point, I have had at least one customer who asked us not to make add fixes in a minor release because that would take extra effort to get through change control; they wanted *exactly the same code* to be called a patch release so fewer testing steps be done. The major downside to this scheme I can see is that it is not obvious from the version *when* the release was made, so a table like this  is required.


Don Knuth's versioning schemes of TeX and Metafont are, let's say... idiosyncratic. They asymptotically approach π and Euler's number, respectively (currently 3.14159265 and 2.7182818). Cute as this might be, thankfully these are exceptional examples.


My first professional OS (I don't count writing university reports in GEOS) was SunOS 4 on SPARC (4.1.3 was a classic release). But when Sun moved from BSD-style SunOS 4 to SVR4-based SunOS 5, the latter was rebranded as Solaris 2.X, with the former series retroactively renamed as Solaris 1. But after Solaris 2.6, the "2.X" prefix was dropped, so thereafter we had Solaris 7, 8, 9, 10, 11... and then we started getting point releases again to the current 11.4. Under the covers, though, the SunOS reference is still visible:

Java versioning made a similar change; things made a jump after JDK 1.4 to "Java 5", but internally, the "1." prefix still exists for (say) Java 8:

except when it's not. For example, this Java 11 installation:

Perhaps the most public change was after Windows 8; there was no Windows 9, and Windows 10 was treated as a different product. Its version adopted the "modern" trend to be the Calendar-Versioning scheme.


I can't help thinking that these marketing changes make things more complex than necessary.


Although I perceive this to be a "modern" trend, some systems have been using it for several years. Notably Ubuntu Linux's first version in Oct 2004 was version "4.10". BMC has moved over to this scheme for Remedy and CMDB from version 9.1 to 19.05, as can be seen here. It is expected that Discovery will do something similar for the next on-premise release, although the last I heard no decision had been made as to exactly what this will be. The clear advantage is:


  • The release year and month should be obvious.


Again, reality does not always coincide with the ideal. For example, OpenWrt's 18.06 release was in July 2018. Perhaps you can forgive one month difference. But OpenWrt 19.07 is still not released, at the time of writing (scheduled for Jan 2020). Windows 10 1809 only made public release in November. 1703 had a public release in April. Moreover there are some disadvantages:


  • It's not clear from a date whether there is a major or minor change, and the associated benefits/risks/effort.


My understand is that this is not supposed to be a problem once all software release cycles are moved closer to a continuous, "agile", model: many small releases where the whole concept of a major release goes away. This is fine as a theoretical limiting case, but I am yet to be convinced it can always be achieved in practice. There are some large changes that just can't be broken down into a series of smaller ones.


I note that even BMC version support documentation seems to be rather confused to me. It's been updated recently (Dec 2019)  to include the format:


  • YY.YY.RR
    • YY.YY= 4-digit year
    • RR=release


But what does this mean? Say, "CMDB 19.11" - only the 2 digits "19" is a year, so does that mean "11" is the minor release? If so, that means that large changes can only take place once a year (major version). Moreover the wording actually asserts exactly one major architectural change per year. That can't be right. And no facilities for service packs/patch numbers here. I have an open question with management from before Christmas; I'll let you know if I get clarification.


All this complexity makes it hard for Discovery to store consistent data too. For SoftwareInstances, we have two attributes:


  • version ("full version"): the internal version, with as much detail as possible
  • product_version ("Product Version"): a higher-level "marketing" version


An example would be for SQL Server:

How does Discovery record Window 10? Not very well, IMHO: we set the version to 10 and don't record the YYMM version at all. I have logged defect DRUD1-25673 back in 2019-03, and I am hopeful this will be fixed in the next on-premise release. Related, is how this would be pushed to CMDB. The BMC_OperatingSystem class has fields VersionNumber and MarketVersion, but we currently make no attempt to distinguish these in the mappings:

I think we should, like for Windows:


  • MarketVersion : Server 2019
  • VersionNumber : 10.0.17763


or for HP-UX:


  • MarketVersion : 11i v2
  • VersionNumber : 11.23


I have DRUD1-26198 open for this, but so far no sign of a fix schedule. As part of a Premier Support contract, I had to resort to writing a (simple) custom pattern for my customer, who originally could only see the "11i" part of their extensive HP-UX estate.



I dedicate this desultory post to the biggest number: 40.