joomla-bcIn this post, I’m continuing along the theme of backward compatibility, and this time, applying it directly to Joomla – specifically, its release policies – and what this means for extension developers like Digital Peak. Bear in mind that Joomla is open-source, which means that in theory, if you really need backward compatibility, you can always hack the source code yourself to implement whichever functions and behaviours that have changed in successive versions.

Joomla is in the rather curious (but hardly unique) position of being both a software package running on top of a platform (in most cases, the LAMP software stack, but it could equally be the WAMP, WIMP or MAMP stacks), as well as being a software platform of its own. Hence, backward compatibility is required both in respect to the platform it runs on, as well as the extensions that it runs.

Joomla’s Software Platform

While Joomla requires a software stack consisting of an OS, a Web server, a database engine and PHP to run, in practice the OS can be just about any version that will successfully install and run the other 3 components of the stack. Judging from previous data, Joomla is not very concerned with backward compatibility between major releases. For example, sometime between v1.5 and v2.5, Joomla dropped support for IIS6, Apache 1.3, PHP4.x and MySQL 4.x – but it also added support for nginx and SQL Server.

It’s hardly surprising – as a FOSS project, the Joomla project does not itself derive any income from licencing the CMS for commercial (or indeed any other) use, and cannot devote resources to supporting the edge cases. Between 2008 (when 1.5 was released) and 2012 (when 2.5 was released), both IIS6 and Apache 1.3 reached end-of-life (EOL) status (which meant neither would be supported by their respective manufacturers beyond the EOL date), while PHP4.x and MySQL 4.x were EOL even before that. Popular CMSes (and fellow FOSS projects) like WordPress and Drupal also dropped support for PHP4.x and MySQL 4.x around the same timeframe, so Joomla was in good company. From this, it can be inferred that Joomla will likely drop support for a particular component of the stack it runs on shortly after the component’s vendor itself drops support for it.

Joomla As Software Platform

What about the people who develop on or for Joomla, then, like Digital Peak? How does Joomla treat us whenever it updates itself? The current Joomla SDLC is a bit more clear-cut about how it treats backward compatibility. Within any individual major release, Joomla is guaranteed to be backward-compatible. That is to say, it will make no changes to its currently-supported APIs or other public surfaces (config and settings files, for instance). Every major release from 3.x onwards will be supported for a minimum of 4 years, presumably with a period of around 2 years between each major release.

Between major releases, however, Joomla makes no such guarantee. New APIs may be introduced, existing APIs may be deprecated, deprecated APIs may disappear completely, settings may be completely jettisoned. Joomla’s core developers see major releases as opportunities to refactor Joomla’s code, introduce new ground-breaking features and generally get rid of any cruft that may have accumulated.

Implications For Developers And Users

As a Joomla developer, Digital Peak has to be open to the possibility that each extension may need a separate version for each major release of Joomla (and perhaps drop support for older, unsupported releases of Joomla). For users, it is a clear signal that in order to stay supported by Joomla’s core developers, a proper upgrade roadmap needs to be in place. Or pay for 3rd-party support.

for-bcIn a previous post of mine, I mentioned that we would look at some of the pros and cons of maintaining backward compatibility. In this post, I take a look at some of the reasons software companies choose, like Microsoft, to make their new products as backward compatible as possible.

Most software companies are for-profit organisations; that is to say, either they make money from licencing their software (rarely is software outright sold), renting their software (the SaaS model) or from selling support services (especially if the software in question is FOSS). In all of these cases, the commercial sector is where the real money is, which the home consumer market can have a massive influence on.

The business market

One of the core reasons why software (and indeed, other) companies decide to allocate resources on backward compatibility is because customers – especially business customers – are generally resistant to change. The less change there is, the better it is – especially if the change has a quantifiable dollar cost attached to it (which would be the case if upgrading one piece of software also required you to upgrade other pieces of software which used to work well with the earlier version but not with the new one). Furthermore, many corporate users of software platforms would also have made their own customisations and installed business-critical add-ins and extensions, so they would be much less willing to buy and install a new version if they could not keep their customisations intact.

In addition, many large organisations have internal IT procurement processes that require regression testing of software upgrades against their standard set of software installed on user machines. A software upgrade that did not break the other software in use has a much greater chance of being approved for purchase (in the case of proprietary software) in a quicker timeframe and deployed in production environments.

Another reason why software vendors – especially enterprise software vendors – maintain backward compatibility is to support customers who rely on custom-made line-of-business applications or modules that relied on the particular set of quirks and behaviours (both explicitly defined and internally) of a specific software version. Many times, the developers of such applications are no longer around to maintain or update their creations, and the source code may have been lost or otherwise unavailable. Breaking backward compatibility is not an option for these customers, who might represent a large chunk of a vendor’s market.

The Catch-22

An interesting scenario occurs once a software platform becomes sufficiently popular and entrenched in a global market, and a healthy ecosystem of independent software vendors (ISVs) develop applications that run on that platform. When that happens, backward compatibility becomes a high priority for both the platform manufacturer as well as its ISVs. For the software platform’s developers, they have to ensure that their next version continues to allow all (or virtually all) of the existing ISV software products to keep running with no changes. The ISVs in turn have to ensure that their next-generation software continues to run on the existing versions of the software platform with next to no changes. In this case, both platform and ISV vendors have a vested interest in maintaining backward compatibility with each other’s current- and previous-generation products.

So what about Joomla, which is itself a software platform? How does it handle backward compatibility? That is a matter for a future post.


I published at the beginning of 2007 the first GCalendar version on the JED, since that time GCalendar has used the Google calendar API v1. It was working well in all this years, but it didn't meet the requirements of modern architecture nowadays and that's why Google decided to build a new API from ground up (v3). It is more secure (OAuth authentication) faster (JSON protocol) and more feature rich (event colors, enc more....). Since the beginning of DPCalendar we us the Google calendar API v3 in our Professional Google Plugin.

As we announced in April this year (2014), Google will shut down their calendar API which GCalendar used since years on the 17. November 2014. We do offer a migration path for GCalendar users to use their existing GCalendar installation with the FREE package of DPCalendar on their Joomla 2.5 or 3.x web site. Yesterday was the day, Google shut down their Google calendar API v1 and v2. Since Sunday we are seeing an increase in traffic and downloads of DPCalendar. Looks like people started to do the migration. Additionally we got GREAT feedback about the evolvement of GCalendar into DPCalendar.

We have big plans for 2015 with DPCalendar and brand new responsive Joomla extensions. More information will be published at the beginning of 2015. We hope that you will have a great time with DPCalendar as you had with GCalendar! Let's move on to new spheres....


In my previous post, I’ve discussed what it means for software to be backward-compatible. Software manufacturers usually come down firmly on this issue one way or the other. An example of a software company that traditionally strives to maintain backward compatibility almost to the point of insanity is Microsoft. Apple (arguably a hardware company), on the other hand, strives to break backward compatibility where it deems it necessary. Of course, most software companies eventually do decide to break backward compatibility; it’s just a question of when. And no software company deliberately makes its every major release incompatible with its previous version (for instance, while Joomla! doesn’t guarantee backward compatibility between major releases, it doesn’t guarantee incompatibility either).

So what would make even a company like Microsoft, much less the Joomla core developers (who, let’s be honest, have less to lose) decide to throw away backward compatibility? What reasons could there be? Here are a few issues that may be factored in when deciding whether to maintain or break compatibility with previous versions of the software in question.

Increased complexity and costs

Backward compatibility can be very hard to maintain. In the case of Microsoft Windows, for instance, many of the smaller developers (and some of the larger ones!) have grown used to poking around its undocumented (internal) functions and data structures in ways that worked for one particular version – but then subsequently had to be maintained or emulated in all subsequent versions of Windows to come. The Sega MegaDrive (Genesis in the USA) could run Sega Master System (its predecessor) games… by including the main Master System processor as a co-processor.

At some point, the overhead associated with backward compatibility outweighs the benefits of maintaining it, and that is when the decision to break it should be taken. For an entrenched OS like Windows with millions if not billons of installs, that may take years or even decades. For something agile like Joomla, that point comes around much quicker.

Security concerns

In the earlier years of PC development, every application could (and often did) consider the entire PC (and by extension, all of DOS, and later, Windows) as its sandbox, and freely manipulated it as it saw fit. Even when Windows NT became the mainstream OS, developers remained quite happy to write applications in such a way as to require Administrator privileges (the Windows equivalent of UNIX-like systems’ root access). Today, such untrammelled freedom is unthinkable, given the massive security breach it would represent. Or at least, that’s how it should be. In practice, given the need to maintain backward compatibility with such applications, workarounds have to be put in place in order to fool them into thinking they could still do things in the same bad old ways. As it turns out, security is now a more important issue in everyone’s eyes, so sacrificing backward compatibility is easier when explained in those terms.

Stifled Innovation

When creating a new version of its software, Microsoft’s primary goal is not to create something innovative and groundbreaking; instead, it is to firstly ensure that it will do no harm to existing systems running the old version(s), and then add new features. For Apple, innovation and usability and delighting the customer comes first; if the price is breaking backward compatibility, it’s not even an agenda item for them to discuss – they just go ahead and do it. However, if the choice was to innovate or die, even Microsoft will throw backward compatibility to the back burner.

bc-part1In this new series of blog posts, I thought I should start off with something that seems as far away from Joomla! as possible, and discuss how the past affects the future. A funny apocryphal story relates the reason why the size of the Space Shuttle’s rocket boosters depended on the width of a horse’s arse (the boosters were limited by the size of the railway tunnels they travelled through from the factory to the launch site, the tunnels were limited by the size of the railway gauge, the railway gauge was chosen by British railway pioneers based on the size of ancient Roman roads, which were based on the size of Roman chariots, which were based on the size of the rear ends of the two warhorses that pulled them).

While the truth is somewhat more complex than the story makes it out to be (go ahead and read it at the link above), it does neatly encapsulate the software engineering principle which we call ‘backward compatibility’. There are many arguments for why this is an important part of software engineering, and equally, there are similar arguments for why backward compatibility should be jettisoned whenever and wherever possible. Joomla, for what it’s worth, is guaranteed to be backward-compatible with all minor (point) releases within a single major release.

Backward compatibility in practice

A good working definition of software that is backward-compatible is if you can perform an in-place upgrade of a previous version, and the software will continue to work (perfectly) with the existing scripts, add-ins, macros, files and settings already in use by the earlier version. On a larger scale, it can be said that backward compatibility is what Service Oriented Architecture (SOA) is intended to achieve, in that any modular component in an SOA system can be changed without impacting any other component. In a more narrow sense, software can be said to be backward compatible if it’s compliant with (and fully implements) the older version’s Application Programming Interface (API). It is in this latter sense that Joomla can be said to be backward compatible within any major release – it will not break API compatibility.

Nor is software the only part of IT that manifests backward compatibility. Hardware components are often backward compatible as well. Many Blu-Ray players will also play DVDs and CDs. By design, USB3 slots will happily accept USB2 and USB1.1 devices and work with them, while USB3 devices will happily plug into – and work in – USB2 and USB1.1 slots, also by design. The latest Intel Core i7 6-core 64-bit microprocessor still starts up in Real Mode (and therefore will run MS-DOS 5.0 or even PC-DOS 1.1 quite happily, albeit with some things to bear in mind). Given that the original 8086 microprocessor was released 36 years ago, that is quite a lot of backward compatibility.

But what are the advantages and/or disadvantages (if any) of backward compatibility, and are there any ‘gotcha’s to supporting backward compatibility? That question is the focus of the next two posts in this series. The fourth post will then focus on how Joomla handles the issue of backward compatibility.

We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.