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.