Back in June it was announced that the next Perl release would be called Perl 7. A quick look back at Perl's history reveals that this is a little unusual. Perl 5 was originally released in October 17, 1994 and served its users well for a number of years. In 2000 Perl 6 was announced as a ground-up redesign of the language and it spent a long time in development. It eventually surfaced in 2015 but in 2019 was renamed "Raku" to distinguish it from traditional Perl. This leaves Perl 6 as a sort of "orphaned" version number.
In the meantime while Raku née Perl 6 was being developed, the team behind Perl 5 had delivery numerous point releases and retained an active community of loyal users. Many of these had no desire to migrate to Raku and wanted a number of quality of life improvements in their language, ecosystem and libraries. The sort of changes being proposed were bigger than you'd expect from a point release, so a new major version was required. Hence Perl 7 - the real next version of Perl.
So we now have quite an interesting situation, let's take a look at the release history:
Version | Date | Comment |
---|---|---|
Perl 4.000 | 21st March 1991 | |
Perl 5.000 | 17th October 1994 | |
Perl 6 | - | Actually "Raku", little resemblance to Perl 5 |
Perl 7 | Planned 2021+ | Refined and improved Perl 5 |
Over the years many commercial and open source projects have skipped version numbers leaving their own little version holes with their own various explanations. Today we'll take a look at a number of similar situations like this, and we'll try to understand what happened in each case and why.
A fairly typical Perl program which calculates π
PHP 6
Perl was not the first language to skip a version, in fact it wasn't even the first scripting language beginning with "P" to skip version 6. A quick glance at PHP's release history reveals the following:
Version | Date | Comment |
---|---|---|
PHP 4.0.0 | 22 May 2000 | |
PHP 5.0.0 | 13 July 2004 | |
PHP 6.0.0 | - | Never released |
PHP 7.0.0 | 3 Dec 2015 |
So what's the story here? Well in common with most
software written in the early '00s PHP did not have particularly good Unicode support. The developers behind
PHP recognised this and planned a rewrite - PHP 6 - that used Unicode to represent strings internally, specifically UTF-16. Work began in 2005 and would continue for a few years. While some of the planned PHP 6 features were completed on schedule, the Unicode rewrite stalled and became a major blocker to the release. In the meantime Unicode did indeed begin to take off ...
... however UTF-16 didn't. UTF-8, a different standard, rapidly emerged as the preferred Unicode standard on the web. This was particularly problematic since it became apparent that PHP 6 had some
serious performance issues dealing with converting strings to and from UTF-8, and
since web applications were PHP's bread and butter this was a big deal.
In 2010, five years into the PHP 6's development the project was abandoned. Much of the non-Unicode features of PHP6 were ported into PHP 5 and released in version 5.4.
In 2014 as a new major release of PHP was being planned the topic of what it should be called
was raised and it was decided that for the sake of removing any
confusion or ambiguity the next version of PHP would be PHP 7. There are
plenty of justifications given, but the first one given in the RFC I
linked really seals it
First and foremost, PHP 6 already existed and it was something completely different. The decimal system (or more accurately the infinite supply of numbers we have) makes it easy for us to skip a version, with plenty more left for future versions to come.
This makes plenty of sense - PHP 6 was already a thing, and it's not like integers are a finite resource. If this was Ubuntu and they were considering discarding a good adjective/animal pair then perhaps it'd be slightly different
ECMAScript 4
Brendan Eich developed Javascript over the course of 10 short days at Netscape, and it soon became the defacto scripting language for the web. This status was confirmed by Ecma who issued a number of standards and referred to it as "ECMAScript". Nowadays they release these standards on a yearly basis (the latest being ECMAScript 2020, published June 2020) but at the end of 2009 we had five ... kinda:
Version | Date | Comment |
---|---|---|
ECMAScript 1 | June 1997 | |
ECMAScript 2 | June 1998 | |
ECMAScript 3 | December 1999 | |
ECMAScript 4 | - |
Abandoned |
ECMAScript 5 | December 2009 |
The first two largely captured and formalised the existing Javascript behaviour, but the committee began to get a little more adventurous in the third version, introducing features like regular expressions and try/catch. I can't find a very good summary other than the Wikipedia one (which seems to be copy-pasted everywhere) and I'm not going to read the entire spec.
Anyway the folks at Ecma recognised the potential of rich client-side web applications, and recognised that in its current state Javascript aka ECMAScript was not particularly well suited this task in its current state:
Though flexible and formally powerful, the abstraction facilities of ES3 are often inadequate in practice for the development of large software systems. ECMAScript programs are becoming larger and more complex with the adoption of Ajax programming on the web and the extensive use of ECMAScript as an extension and scripting language in applications. The development of large programs can benefit substantially from facilities like static type checking, name hiding, early binding and other optimization hooks, and direct support for object-oriented programming, all of which are absent from ES3.
For ECMAScript, we here on the IE team certainly believe that thoughtful evolution is the right way to go; as I've frequently spoken about publicly, compatibility with the current web ecosystem - not "breaking the Web" - is something we take very seriously. In our opinion, a revolution in ECMAScript would be best done with an entirely new language, so we could continue supporting existing users as well as freeing the new language from constraints (including the constraint of performantly supporting scripts written in the old language)
You seem to be repeating falsehoods in blogs since the Proposed ECMAScript 4th Edition Language Overview was published, claiming dissenters including Microsoft were ignored by me, or “shouted down” by the majority, in the ECMAScript standardization group
...
These ES3.1 proposals came suddenly in March after years of passive participation by Microsoft, while the rest of the group worked on ES4. They have not been touched since April.
IPv5
Version | Date | Comment |
---|---|---|
IPv0 | March 1977 | |
IPv1 |
February 1978 | |
IPv2 |
February 1978 | |
IPv3 | February 1978 |
|
IPv4 | June 1978 | |
IPv5 | - | Abandoned? |
IPv6 | December 1995 |
Note: For IPv6 we could linked RFC 1883 (where it was first specified) or RFC 8200 (which made a few additional changes to the protocol)
So the only real missing version is IPv5 - which actually spent a couple of decades being defined as the "Internet Stream Protocol", never really went anywhere and is effectively abandoned. Honestly though if you're interested you should check out this article by Matthäus Wander. I spent ages bouncing around different RFCs and IENs and couldn't really piece everything together until Matthäus laid it all out so go read his article.
IPv6 adoption is slow and steady, currently sitting at 33% worldwide as of 16th October 2020
Node.js 1.0.0 to 3.0.0
Node.js came into existence in 2009, promising developers that they could implement performant backend code in a simple language like
Javascript thanks in no small part to Google's V8 engine. I personally played with it a bit every now and then and used things like Ghost, but no more than every couple of months. Then one day I tried to run some example code only to find it didn't work and was 5 major versions out of date. I was pretty confused and tried to figure out if there was some reason I was so far behind. A quick look through Node.js' release history reveals the reason behind my confusion:
Version | Date | Comment |
---|---|---|
Node.js 0.10.0 | 11 March 2013 | |
Node.js 0.11.0 | 28 March 2013 | |
Node.js 0.12.0 | 6 February 2015 | |
Node.js 1.0.0 | - | Never existed |
Node.js 2.0.0 | - | Never existed |
Node.js 3.0.0 | - | Never existed |
Node.js 4.0.0 | 8 September 2015 | |
Node.js 5.0.0 | 29 October 2015 |
Version | Date | Comment |
---|---|---|
Node.js 0.10.0 | 11 March 2013 | |
Node.js 0.11.0 | 28 March 2013 | |
io.js 1.0.0 | 14 January 2015 | |
Node.js 0.12.0 | 6 February 2015 | |
io.js 2.0.0 | 4 May 2015 | |
io.js 3.0.0 | 4 August 2015 | |
Node.js 4.0.0 | 8 September 2015 | |
Node.js 5.0.0 | 29 October 2015 |
Java 2.x to 4.x
Version | Date | Comment |
---|---|---|
JDK 1.0 | January 1996 | |
JDK 1.1 | February 1997 | |
J2SE 1.2 | December 1998 | |
J2SE 1.3 | May 2000 | |
J2SE 1.4 | February 2002 | |
J2SE 2.0 | - | Never existed |
J2SE 3.0 | - | Never existed |
J2SE 4.0 | - | Never existed |
J2SE 5.0 | February 2004 | |
Java SE 6.0 | December 2006 |
Both version numbers "1.5.0" and "5.0" are used to identify this release of the Java 2 Platform Standard Edition. Version "5.0" is the product version, while "1.5.0" is the developer version. The number "5.0" is used to better reflect the level of maturity, stability, scalability and security of the J2SE.The number "5.0" was arrived at by dropping the leading "1." from "1.5.0". Where you might have expected to see 1.5.0, it is now 5.0 (and where it was 1.5, it is now 5).
DirectX 4
Version | Date | Comment |
---|---|---|
DirectX 1 | 30 September 1996 | |
DirectX 2 |
5 June 1996 | |
DirectX 3 | 15 September 1996 | |
DirectX 4 | - | Never released |
DirectX 5 | 4 August 1997 | |
DirectX 6 | 7 August 1998 |
Watcom 5.0 and earlier
Version | Date | Comment |
---|---|---|
Watcom 5.0 | - | Never existed |
Watcom 6.0 | 1988 | |
Watcom 7.0 | 1989 | |
Watcom 8.0 | 1990 |
Slackware 5 and 6
For some reason Slackware was the first ever Linux distro I used. I have
no idea why I chose it, but looking back it would've been better if I
had a more user-friendly one like RedHat or SuSE. Using software on
Slackware often involved compiling it yourself, which usually meant
hunting down, downloading and compiling dependencies (possibly even
encountering more dependencies which require you to hunt down, download and compile sub-dependencies (possibly even encountering more dependencies ... etc)). Between May and October in 1999 they jumped from using 4.0 to 7.0
Version | Date | Comment |
---|---|---|
Slackware 1.0 | 17 July 1993 | |
Slackware 2.0 | 2 July 1994 | |
Slackware 3.0 | 30 November 1995 | |
Slackware 4.0 | 17 May 1999 | |
Slackware 5.0 | - | Never existed |
Slackware 6.0 | - | Never existed |
Slackware 7.0 | 25 October 1999 |
I think it's clear that some other distributions inflated their version numbers for marketing purposes, and I've had to field (way too many times) the question "why isn't yours 6.x" or worse "when will you upgrade to Linux 6.0" which really drives home the effectiveness of this simple trick. With the move to glibc and nearly everyone else using 6.x now, it made sense to go to at least 6.0, just to make it clear to people who don't know anything about Linux that Slackware's libraries, compilers, and other stuff are not 3 major versions behind. I thought they'd all be using 7.0 by now, but no matter. We're at least "one better", right? :)
- Mandrake 6.1 (released September 1999)
- RedHat 6.1 (released September 1999)
- SuSE 6.2 (released August 1999)
- Debian 2.1 (released March 1999)
SuSE, Mandrake and Ubuntu oddities
Version | Date | Comment |
---|---|---|
SuSE Linux 4.0 | - | Never existed |
SuSE Linux 4.1 | - | Never existed |
SuSE Linux 4.2 | May 1996 | |
SuSE Linux 4.3 | September 1996 |
Version | Date | Comment |
---|---|---|
Mandrake 4.0 | - | Never existed |
Mandrake 5.0 | - | Never existed |
Mandrake 5.1 | July 1998 | |
Mandrake 5.2 | December 1998 | |
Mandrake 5.3 | February 1999 |
Version | Date | Comment |
---|---|---|
Ubuntu 2.xx | - | Never existed |
Ubuntu 3.xx | - | Never existed |
Ubuntu 4.10 | October 2004 | |
Ubuntu 5.04 | April 2005 | |
Ubuntu 5.10 | October 2005 |
Conclusion
I only scratched the surface of this subject, really. If look around then you'll start to see missing versions everywhere. For example, what happened to Windows 9? How about .NET [Core] 4, MySQL 6 and 7 or Akumulátor 2? As soon as you apply an sequential version to some software you make a statement about how that software relates to any previous or future releases - whether or not you adhere to a strict set of rules like semver. This is meant to help users and it largely works as intended but does not really give any strong prescription for how to handle abandoned releases or forked-then-remerged projects. As a consequence we have to be cool with the idea that skipping a version or two is perhaps preferable than introducing confusion or even discarding any notion of sequence whatsoever - imagine wondering if it's safe to upgrade from PHP e1daa19 to PHP caf3c64.