I'm trying to figure out how backward compatibility works with APIs that include libraries and packages—not just REST servers. If you're working with an older codebase along with newer code, how many external package versions do you need to import to keep the old modules functional while still benefiting from new features in the latest modules? This is quite crucial for me. Also, quick side question: do you guys use a bundler?
4 Answers
In my experience, I've never used more than one version of a library within the same package. Java and Maven enforce that restriction well. However, when we consider the entire software stack, well, you might end up with various versions due to technical debt and legacy code.
In a previous legacy application, we ended up with three different versions of the same third-party library—using the latest version but needing an older one for another library. Those compatibility issues only showed up at runtime, which made debugging a pain. We faced a similar situation with libraries like SharpZipLib and RestSharp a while back.
I had a situation recently where I had to manage three libraries with two different versions for multiple applications. It was a nightmare! We hit a wall with maintaining them. If you see that coming, take a day to address that tech debt before it gets overwhelming.
I usually stick to just one version of each library. The only exception was a project for a well-known international bank where they insisted on supporting .NET Framework 4.7. They had their version of the library, which has now become a unique case.
Exactly! Sometimes you work on big projects with tons of files and can't easily rewrite everything to match the updated libraries. Corporate pressure often means you can't tackle breaking changes, even if the newer versions offer better features.