Backward Compatibility

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?
    Backward compatible pin layout of Raspberry Pi 4 Model B. Source: Adapted from Pi4J 2021a
    Backward compatible pin layout of Raspberry Pi 4 Model B. Source: Adapted from Pi4J 2021a and Pi4J 2021b.

    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?
    Downward, upward, backward and forward compatibility. Source: van Ommering 2001, fig. 3.
    Downward, upward, backward and forward compatibility. Source: van Ommering 2001, fig. 3.

    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?
    Changes that break binary backward compatibility. Source: Ponomarenko and Rubanov 2012, table 1.
    Changes that break binary backward compatibility. Source: Ponomarenko and Rubanov 2012, table 1.

    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?
    Service A maintains two API versions leading to technical debt. Source: Sundelin et al. 2020, fig. 1.
    Service A maintains two API versions leading to technical debt. Source: Sundelin et al. 2020, fig. 1.

    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
Colour television transmission. Source: Adapted from Britannica 2020.
Colour television transmission. Source: Adapted from Britannica 2020.

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
Backward and forward compatibility due to RoHS Directive. Source: Pan et al. 2007, table 1.
Backward and forward compatibility due to RoHS Directive. Source: Pan et al. 2007, table 1.

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.

References

  1. Atlassian. 2018. "Atlassian REST API policy." Atlassian Marketplace, Atlassian Developer, February 14. Accessed 2022-05-08.
  2. Bos, Bert. 2003. "Backward Compatibility." In: What is a good standard?, W3C, March 6. Accessed 2022-05-08.
  3. Brandi, Paolo. 2019. "Android API Level, backward and forward compatibility." On Medium, June 10. Accessed 2022-05-19.
  4. Breiter, Michał, and Robert M. Nowak. 2019. "The new C++ serialization library supporting backward and forward compatibility." Proc. SPIE 11176, Photonics Applications in Astronomy, Communications, Industry, and High-Energy Physics Experiments 2019, 111761P, November 6. doi: 10.1117/12.2536387. Accessed 2022-05-13.
  5. Britannica. 2020. "The picture signal." Encyclopædia Britannica, Inc., January 31. Accessed 2022-05-13.
  6. Britannica. 2020b. "Android Operating System." Encyclopædia Britannica, Inc., August 27. Accessed 2022-05-13.
  7. Clerkin, Sean. 2020. "The Pros and Many Cons of Backwards Compatibility." TN2 Magazine, March 26. Accessed 2022-05-08.
  8. D'Andrea, Christian. 2015. "Schadenfreude Fridays: The Atari 5200, the Console that Never (Should Have) Existed." Anchor of Gold, Vox Media, LLC, April 17. Accessed 2022-05-19.
  9. ETSI. 2010. "TS 129 199-1: Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Open Service Access (OSA); Parlay X web services; Part 1: Common." V9.0.0, January. Accessed 2022-05-08.
  10. European Commission. 2022. "Restriction of Hazardous Substances in Electrical and Electronic Equipment (RoHS)." European Commission. Accessed 2022-05-20.
  11. Google. 2022. "Language Guide (proto3)." Documentation, Protocol Buffers, Google Developers, May 12. Accessed 2022-05-14.
  12. Google Cloud. 2022. "Compatibility." Cloud APIs, Google Cloud, February 10. Accessed 2022-05-08.
  13. Gramila, John. 2021. "Protocol Buffers Best Practices for Backward and Forward Compatibility." Blog, Earthly, May 21. Accessed 2022-05-08.
  14. Heidel, Steven. 2020. "Backward vs. Forward Compatibility." On Medium, August 11. Accessed 2022-05-13.
  15. Hodgson, Pete, and Patricio Echagüe. 2019. "Chapter 6. Best Practice #4: Incremental, Backward-Compatible Database Changes." In: Feature Flag Best Practices, O'Reilly Media, Inc. Accessed 2022-05-14.
  16. Jacobs, Marco, and Jonah Probell. 2007. "A Brief History of Video Coding." ARC International. Accessed 2022-05-13.
  17. Johnson, Hugues. 2022. "History of Backwards Compatibility." Accessed 2022-05-19.
  18. Krechmer, Ken. 2000. "The Fundamental Nature of Standards: Technical Perspective." IEEE Communications Magazine, vol. 38, no. 6, pp. 70-80, June. Accessed 2022-05-13.
  19. Ling, Rich. 2005. "Interest in future net-based services for a sample of Norwegian interviewees." In: Future Mobile Phones, Telektronikk, vol. 101, no. 3/4. Accessed 2022-05-13.
  20. Lo, Peggy. 2020. "Xbox Series X and Xbox Series S Will Be the Best Place to Play 1000s of Games From Across Four Generations of Xbox." News, Xbox, October 13. Accessed 2022-05-14.
  21. Moore, Kevin D. 2019. "Android SDK Versions Tutorial With Kotlin." Tutorial, Razeware LLC, May 20. Accessed 2022-05-19.
  22. Nahm, Jae. 2001. "The Effect of Compatibility on Software Supply and Hardware Demand: Forward and Backward Compatibility." The Economics of the Software and Internet Industries, Toulouse, France, January 18–20. Accessed 2022-05-19.
  23. PC Magazine. 2022. "forward compatible." Encyclopedia, PC Magazine. Accessed 2022-05-08.
  24. Pan, J., J. Bath, X. Zhou, and D. Willie. 2007. "Backward and Forward Compatibility." In: Bath, J. (eds), Lead-Free Soldering, Springer, Boston, MA. doi: 10.1007/978-0-387-68422-2_7. Accessed 2022-05-20.
  25. Pi4J. 2021a. "Pin Numbering - Raspberry Pi Model A." Version 1.4, The Pi4J Project, March 1. Accessed 2022-05-13.
  26. Pi4J. 2021b. "Pin Numbering - Raspberry Pi 4B." Version 1.4, The Pi4J Project, March 1. Accessed 2022-05-13.
  27. Ponomarenko, A., and V. Rubanov. 2012. "Backward compatibility of software interfaces: Steps towards automatic verification." Programming and Computer Software, vol. 38, pp. 257–267. doi: 10.1134/S0361768812050052. Accessed 2022-05-20.
  28. Pratt, Michael. 2020. "Ensuring backwards compatibility in distributed systems." Blog, StackOverflow, May 13. Accessed 2022-05-08.
  29. Raspberry Pi. 2022. "Operating system images." Raspberry Pi. Accessed 2022-05-13.
  30. Ronald, Jason. 2019. "E3 2019: What’s Next for Xbox Backward Compatibility." News, Xbox, June 10. Accessed 2022-05-08.
  31. Sangani, Kris. 2011. "Software backwards compatibility." E&T, The Institution of Engineering and Technology, September 12. Accessed 2022-05-08.
  32. Schmidt, Konstantin, Markus Schnell, Nikolaus Rettelbach, Manfred Lutzky, and Jochen Issing. 2009. "On the Cost of Backward Compatibility for Communication Codecs." ISCA, September 6-10. Accessed 2022-05-08.
  33. Soh, Pek-Hooi, and Edward B Roberts. 2003. "Networks of innovators: a longitudinal perspective." Research Policy, vol. 32, no. 9, pp. 1569-1588. doi: 10.1016/S0048-7333(03)00065-9. Accessed 2022-05-13.
  34. Spector, Lincoln. 2012. "Old vs. new Microsoft Office file formats." PCWorld, December 24. Accessed 2022-05-13.
  35. Sundelin, Anders, Javier Gonzalez-Huerta, and Krzysztof Wnuk. 2020. "The hidden cost of backward compatibility: when deprecation turns into technical debt - an experience report." Proceedings of the 3rd International Conference on Technical Debt (TechDebt '20), Association for Computing Machinery, New York, NY, USA, pp. 67-76. doi: 10.1145/3387906.3388629. Accessed 2022-05-08.
  36. Vjestica, Adam. 2022. "Inside Xbox’s backward compatibility journey with Series X development chief, Jason Ronald." TechRadar, January 15. Accessed 2022-05-08.
  37. Webopedia. 1996. "Upward Compatible." Webopedia, September 1. Updated 2021-05-24. Accessed 2022-05-08.
  38. Zalando. 2022. "REST Design - Compatibility." zalando/restful-api-guidelines, on GitHub, January 26. Accessed 2022-05-08.
  39. commorancy. 2018. "A history of the DIVX DVD." Random Thoughts – Randocity!, April 29. Accessed 2022-05-19.
  40. van Ommering, Rob. 2001. "Independent Deployment - the Reason behind Components?" Philips Software Conference, March. Accessed 2022-05-08.

Further Reading

  1. Pacheco, Diego. 2020. "Thoughts on Backward and Forward Compatibility." Blog, May 13. Accessed 2022-05-08.
  2. van Ommering, Rob. 2001. "Independent Deployment - the Reason behind Components?" Philips Software Conference, March. Accessed 2022-05-08.
  3. Google Cloud. 2022. "Compatibility." Cloud APIs, Google Cloud, February 10. Accessed 2022-05-08.
  4. Heidel, Steven. 2020. "Backward vs. Forward Compatibility." On Medium, August 11. Accessed 2022-05-13.
  5. Krechmer, Ken. 2000. "The Fundamental Nature of Standards: Technical Perspective." IEEE Communications Magazine, vol. 38, no. 6, pp. 70-80, June. Accessed 2022-05-13.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
2
2
1358
2
0
165
1674
Words
2
Likes
3535
Hits

Cite As

Devopedia. 2022. "Backward Compatibility." Version 4, May 20. Accessed 2023-11-12. https://devopedia.org/backward-compatibility
Contributed by
2 authors


Last updated on
2022-05-20 04:59:03

Improve this article

Article Warnings

  • Readability score of this article is below 50 (46.2). Use shorter sentences. Use simpler words.