# Backward Compatibility

## Summary


Technology is rarely static. Technical specifications and products based on them evolve continually. When new versions are released, we can't simply throw away old versions and ask everyone to upgrade. There's a need for new versions to interwork with older versions. This is what we mean by **backward compatibility**.  

Industry bodies that define standards must consider backward compatibility. Within companies, when technologies and products are evolved, product managers, architects and developers must consider backward compatibility. Backward compatibility ensures that customers can continue to use current products and services without being forced to upgrade. Customers can plan a phased migration towards latest versions.

Backward compatibility is not without its critics. It has the negative effect of prolonging older technologies. Industry may become reluctant in adopting latest technologies unless they offer significant benefits. There's also an additional cost for designing and maintaining backward-compatible implementations.

## Discussion

### Which technology layers need to consider backward compatibility?

Backward compatibility is applicable at both hardware and software levels. In **hardware**, it's about pin compatibility so that old peripherals can interface with newer versions of the system hardware. It can also be about clock synchronization, signal levels or timing so that different hardware components can interwork correctly.

In **software**, backward compatibility is defined for open or public interfaces of software components or products. This is essential when products are being built from many third-party components. At the **system level**, newer hardware should support older software. 

Modern software often rely on web APIs for specific functionality. The **API layer** needs to be backward compatible so that calling a newer version of the API doesn't require changes in client software.  In general, any communication **protocol** (including for instance ISO, IETF or IEEE standards) must be evolved in a backward-compatible manner.

Backward compatibility applies to the **data layer** as well. Data is stored, encoded and decoded in specific formats and versions. However, as data readers and processing tools evolve, they must be able to read and understand older formats. This also applies to how **database schemas** are evolved. 


### What are some examples of backward compatibility?

The Raspberry Pi hardware has evolved through many revisions. The functions of the 26 pins present in the original Model 1A were changed in a backward-compatible manner, that is, Do Not Connect (DNC) pins are mapped to 5V, 3.3V or GND; and other pins are unchanged. This means that peripherals that could connect to Model 1A via the header can also connect to Model 4B.  From a software perspective, recent releases of 32-bit Raspberry Pi OS will work on Model 1A as well. 

The success of Palm Pilot is partly attributed to its ability to hot sync with Microsoft Windows and connect to PCs via USB ports. By supporting existing interfaces, Palm Pilot enabled vendors and users adopt it more easily. 

Microsoft Office 2007 introduced a new format to save documents and spreadsheets: `*.docx` and `*.xlsx` that are essentially based on XML. However, Office 2007 can read from and save to `*.doc` and `*.xls` legacy formats. 

In cellular telecom, CDMA2000 1xEV-DO and CDMA2000 1xEV-DV can interwork with CDMA2000 1X and cdmaOne. 


### What's the difference between backward and forward compatibility?

Consider a client-server example in which different versions of clients and servers operate. If the new server version works with all clients that worked with the old server version, then it's backward compatible. If the new server version will continue to work with all clients in any future update, then it's forward compatible. In the figure, \(S\) is backward compatible with \(S^{-1}\) and forward compatible with \(S^{+1}\). We could say that, 

> When a product or interface is said to be forward compatible, it is really a statement of intent that future versions of the product will be designed to be backward compatible with this one.

Forward and backward compatibility are also called upward and downward compatibility, though some sources apply the former terms to versions of the same entity and the latter terms to communicating entities. 

New software that can read data in older formats is considered backward compatible. Old software that can read newer formats (by skipping unknown fields) is forward compatible.  But it's a matter of perspective. We can say that the new format itself is backward compatible.


### What are the different types backward compatibility?

Source compatibility means that software compiles even when some dependencies have been updated to a newer version. With binary compatibility, code compiles and also links to newer components. Wire compatibility is applicable to communication protocols. It means that two entities (such as client and server) can communicate even when they're running different protocol versions. Semantic compatibility implies that communicating or interfaced entities process or interpret the messages correctly. 

When products, protocols or standards evolve, we talk about each version being backward compatible with earlier versions. Another kind of backward compatibility is about new technologies interworking with older ones. When CSS came out, it allowed developers to continue styling concrete elements in HTML documents. 


### What are the main techniques to achieve backward compatibility?

It's okay to add new interfaces, new operations to existing interfaces or new optional parameters to existing operations. Anything else runs the risk of breaking backward compatibility. In particular, avoid changing the order of enumeration values, removing or renaming operations, and adding mandatory parameters to existing operations.  Don't change field semantics or make input validation more restrictive. 

Avoid versioning. Instead prefer to add a new resource or new endpoint. Where not possible, server deployments can run multiple versions in parallel and retire older versions gracefully. Upgraded servers should check for client support before invoking new features. When clients upgrade to newer interface versions, they should support all mandatory features. Communicating entities can negotiate revision levels and ignore features that are not mutually understood. Some call this an **etiquette standard**. 

Following Postel's Law, clients can be conservative with requests and tolerant of API extensions. However, against Postel's Law, servers should return useful feedback for unknown or invalid inputs. 

Obey technology-specific rules. For example, message types in Protocol Buffers can be evolved in a backward-compatible manner by following specific rules.  


### What's the cost of making technology backward compatible?

In the world of microservices, it's common for a service to maintain multiple versions of the API. Older versions are deprecated but clients continue to use them over a long period of time. This creates a technical debt, particularly for integration tests.  

Backward compatibility can come in the way of innovation. The need to continue with older technologies and make them coexist with newer technologies becomes a challenge. The final solution would also be more expensive for both vendors and consumers. Sony's PS3 is an example. It included additional hardware for backward compatibility with PS1 and PS2. Back in the early 1990s, Europeans invented GSM without attempting to make it backward compatible with various standards. This allowed them to apply state-of-the-art technologies. 

Backward compatibility can lead to less efficient solutions. Reduced codec efficiency was shown in a study of G.722 when extended for super-wideband. 

## Milestones

1950

The Radio Corporation of America (RCA) introduces the first **backward-compatible colour television system**. In 1952, this is accepted as a standard for broadcast television in the U.S. by the National Television Systems Committee (NTSC). Information is composed of luminance (brightness) and chrominance (colour) components. Luminance carries the finer details and is allocated more bandwidth. Chrominance component, which consists of hue and saturation, is ignored by B&W TV receivers.  

1982

**The Atari 5200** console is launched. However, it's **not backward compatible**, meaning that Atari 2600 games can't be played on Atari 5200. Later, Atari gives way to consumer pressure and creates an adaptor so that 2600 games could be played on the 5200. 

1998

Circuit City introduces a new DVD rental format called **DIVX** (aka Digital Video Express). Unfortunately, the DIVX format needs a DIVX player since current DVD players don't understand this format. DIVX players themselves are backward compatible: they can play both DIVX and DVD formats. However, backward compatibility actually backfires for DIVX commercially. In 1999, DVD format continues to be more popular than DIVX. 

2003

Under EU laws, Restriction of Hazardous Substances (RoHS) in electrical and electronic equipment is defined. In July 2011, the **RoHS Directive** comes into force. Among the ten substances are lead. During the early transition period, tin-lead components are assembled with lead-free paste (forward compatibility). During the late transition period, some high reliability applications continue to use conventional tin-lead paste with lead-free components (backward compatibility). 

2007

**Microsoft releases Office 2007** that supports newer XML-based file formats. However, it's can read and write in older formats and hence **backward compatible**. While the earlier Office 2003 was not designed to be forward compatible, it's possible to update Office 2003 so that it can read newer formats. 

2008

The first phone using Android OS is launched. Apps for this OS are built using the **Android SDK**, which is **forward compatible** but not backward compatible. Apps built with a specific `compileSdkVersion` (further qualified by `targetSdkVersion`) will run on newer Android versions as well. This is because old APIs are deprecated but never removed. 

2015

Microsoft announces the **Xbox One Backward Compatibility** program. The aim is to run original Xbox and Xbox 360 games on newer Xbox One consoles. By 2019, over 600 Xbox and Xbox 360 games could be played on newer generation hardware including the use of newer hardware features. With Xbox Series X and S, backward compatibility becomes an essential requirement. This also helps in preserving older games. Moreover, legacy games benefit from the latest hardware with features such as Auto HDR and doubled framerate.