Version and Derision
You’ve seen version numbers in software. 1.0, 2.1, 1.1.0 and sometimes much more complex schemes. Sometimes they get confusing — is 1.1.10 newer than 1.1.2? Yes. Is 4.1a newer than 4.1? It depends.
Usually though, schemes make sense within the context of the software itself, with approximately increasing versions.
Back to the 1990s
Most of you will at least remember some of the tech from the 1990s — apart from being the start of the modern internet as we know it now, software companies sometimes liked at the time to name their software after years, or otherwise play one-up games. This is why it’s called “Windows 95”, for 1995 (duh!) and Windows 98, Windows 2000, etc. Yes, this was particularly a Microsoft trick.
The 1990s was also when Java was popularized as an application programming language. This was contemporary to Visual Basic, Visual C++, Turbo Pascal, etc.
Java was originally developed by Sun Microsystems. Microsoft (yes, there’s a theme here), jumped on the bandwagon and made their own version. There was one hitch though — their JNI (Java Native Interface) was not compatible. That is the interface that let you call native system code — typically various libraries in C/C++.
During my first job out of college, I ended up wrangling with this problem, and I ended up criticizing Microsoft one too many times, which earned a reprimand from my boss — “I don’t ever want to hear you deride Microsoft again”, or words to that effect. At the time, they were a very polarizing company — much more than nowadays.
In any case, as I mentioned, it was Sun that had come up with Java, and would continue to develop it and produce new versions. Again, Microsoft had being playing games with versions, and had produced a version 10. I don’t recall the precise version number Sun had at the time, but the boss quipped, in all seriousness, “Microsoft are already at version 10”.
I guess it must be better? Explaining anything else to him was probably lost on him at this point.
Another One
Much, much later, my employer at the time was engaged with another very large tech company (I won’t say who they are, it’s not that important, but you’ve heard of them). They proposed an particularly long and complex versioning scheme. Unfortunately I don’t have the example to hand, because it was quite something. But what I’m going to show here is what I think it might have looked like, so you get the idea:
<Date>-<our version≥-<their version>-<project name>-<other numbers>R
On the call that this was initially proposed, I expressed my strong reservations that this was too complex and would cause confusion. This was largely ignored by the company (or perhaps, the party that came up with it). My supervisor at the time (and overly loud person, with issues of his own), tried to wave me off during the call, and later told me “I wish you hadn’t mentioned that”, as he tried to pretend there weren’t issues.
As an aside, the representative at the tech company who dreamed up this scheme had been known for their emails with sections highlighted in red bold, and to use words like “trending” when talking about release dates.
Despite all that, there was one particularly nagging and odd feature of the versioning they’d chosen. A magic ‘R’ at the end. After much confusion, it turned out this meant “respin”. What? And that did that mean — a rebuild, some updates, what? And how would we keep track of those “respun” versions.
Very shortly after, the complex versioning most definitely cause confusion, just as predicted. If memory serves, we managed to wrangle a sane scheme, much later on.
Resolution?
Some what later, the tech company decided that another restructure was in order (this had been the second team we dealt with), and a third team was put in place, with perhaps less gusto, but more sanity when it came to versioning.
In in the end of course, it didn’t matter. The tech company treated as quite poorly, and the relationship ended.
But you should still use a sensible versioning scheme.
