Infinity backward compatibility issues

( c )

Backward compatibility with reference to hardware or software systems means the ability to successfully use interfaces and data from earlier versions of the system. This principle applies not only to programs that work with files created in earlier versions of the same programs, but also concerns situations of working with similar algorithms. For example, Perl maintains backward compatibility with another language, Awk , which Perl was intended to replace.

Backward compatibility is easier to perform if previous versions of the system were developed with support for built-in functions such as hooks, plug-ins or APIs that allow you to add new features to your software, but everything from backward compatibility (with an emphasis on back ) can be a headache for developers. .

If you give up on it completely, users of previous versions of systems and products will be upset, instantly losing the entire fleet of accumulated gadgets or programs. You will provide full backward compatibility - you will become a hostage of past decisions, making your product heavy, unwieldy, or even incapable of the desired performance gain.

The developer every time makes the difficult decision: whether the product should be backward compatible. There is simply no “objectively correct” solution here - there are enough examples of successful backward compatibility and refusals from it in the world. Perhaps someone’s experience will help you make the right choice right now.

Let's change the standard again

One of the most prominent examples when it was decided to forget about backward compatibility is the appearance of a USB 3.1 Type C connector (USB-C). For many years we had no problems: any gadget with a micro or miniUSB connector could be plugged into any appropriate USB port. But the USB-IF consortium has created a Type C connector, mechanically completely incompatible with any of the hundreds of millions or even billions of smartphones, cables, chargers and other gadgets.

Another problem is that not every USB-C cable, port, device, and power is compatible with each other: some cables with USB-C on both ends can transfer only 5 Gb / s, others are compatible with 10 Gb / s, and There are those that can not be used for food.

The situation is familiar to those who once collected their own computers themselves or engaged in their upgrade. Over the past 20–30 years, many generations of tires and ports have changed before our eyes, almost every one of which was not backward compatible with the previous ones. Literally all the connectors on the motherboard have changed, and not just once: processor sockets, video card and RAM busses, connectors for connecting drives and peripherals.

Unhealthy mess in the world of processors continues to this day: quite a vigorous models that drive and drive, after a few years can not be put on new motherboards. Manufacturers find it difficult to resist the temptation to regularly make useless iron stores with users, forcing them to carry money for new models. The lack of backward compatibility does not warm the soul when the processor purchased three years ago has to be changed to almost the same because the motherboard has died.

The universal connector, designed for data and power, can become the only port on the device - and this is a definite plus USB Type-C. You can accept the lack of backward compatibility in gadgets, and even note for yourself the advantages (higher data transfer speed and other power supply parameters), but in the software field, the incompatibility of the new versions with the old ones is more painful. This is especially true of corporate products, the cost of which and the impact on business processes are too great.

Gamedev

In the PC ecosystem, games have been backward compatible for decades. Utilities such as DOSBox allow us to play even the earliest PC releases. The compatibility factor, in which the transition to a new version of the system with a high probability does not entail problems, seems to have played a role in the current dominance of Windows. Yes, as a result, 32-bit versions of Windows supported the launch of 16-bit Windows software and some MS-DOS software (and 64-bit versions, respectively, 32-bit programs), but Microsoft got a huge heavy platform in which there are compatibility even with errors.

And how are things with consoles?

Ars Technica report showed how Xbox One and Xbox 360 users use their devices. Interestingly, the data from the report on the console Microsoft coincides with the opinion of Sony Corporation, which does not consider backward compatibility in the PlayStation 4 as something important. According to the head of Sony Interactive Entertainment Europe, Jim Ryan, this feature is more talked about than actually used. Although Sony did provide the ability to download games for PS1 and PS2 on PS4.

Some sites conducted their own polls on the eve of the release of the Xbox One and PS4 - then it was noted that many players expressed the desire for backward compatibility. Microsoft has drawn a lot of attention to backward compatibility with the Xbox One. The function was generally well implemented, but now it does not really attract gamers.

Nintendo DS and Wii also have many examples of backward compatibility.
Game developers have been more enthusiastically met with game developers - no longer need to learn architecture from scratch to take advantage of the new console equipment. Backward compatibility makes it relatively easy to maintain releases for all devices built on a common architecture.

Backward compatibility in languages

( c )

Each popular programming language has a clear evolution, most of its life indicated by the version: you have Java 5, 6, 7, etc., PHP 5.1, 5.2, 5.3, etc. Each new version fixes bugs and adds functions, but if the language (or platform) has fundamental flaws, then the developers either avoid them (if they can) or learn to live with them.

Language developers receive a lot of feedback from programmers using a particular programming language in their work. It seems that one day there will be a version of the language in which all problems will disappear. But this is not happening. Why is that? One option is backward compatibility.

Popular PHP has flaws, and those who have been working with it for a long time know perfectly well how to get around all the pitfalls and pits of the language. Now suppose that in the new version of the language, all the minuses were corrected, but they lost backward compatibility. As a result, the developer spends time updating the code to the current version of PHP. The very time he could spend on fulfilling customer requests or introducing new features.

Given these problems, the motive of those who do not want to switch to a new version of PHP is understandable, even if it is better, clearer and safer, etc. You will say that this is a hypothetical example. Perhaps ... But there are still programmers in the world who are still working on COBOL ! The language appeared in 1958. By 1997, about 240 billion lines of COBOL code was actively used , the code in this language processed about 90% of financial transactions in the world and 75% of commercial transactions. The most interesting thing is the amazing compatibility of the language: the COBOL that was used in the 60s can also work on modern equipment.

There are products that, in principle, can not break backward compatibility, because it will put a cross on them. For example, Java: the main scope of this language is business applications, an astronomical number of lines of code are written around the world, including in huge corporate code databases. Code written 20 years ago still works. And if tomorrow comes the version of Java, in which developers will create fantastic features, but without backward compatibility, then no one will invest much big money in developing serious - and expensive - applications. So, Oracle will either have to pull the load of old versions behind itself, or open the way for innovations, but at the same time losing a large share of customers. On the third option - to support simultaneously two Java branches, with full-fledged maintenance and development - the corporation will not agree.

At one time, the developers of Python violated backward compatibility, thereby making a bunch of users angry. Most programmers did not consider the language of Python 2.x "erroneous" or containing "fundamental flaws". They did not have such complaints, which appear on PHP developers.

Today the language community is divided into two camps, while the mass of ready-made libraries for the second version does not allow many to migrate to the third, although it introduced a number of strong improvements to the language. As a result, the opinion was fixed that " Python 3 is the worst thing that could happen to the Python community ."

The problem has a downside - Python 3 was released in December 2008, but language support in the Django framework appeared only five years later.

Although there is no 100% compatibility between C and C ++, but even in C ++ there is backward compatibility with very early language functions (including some functions inherited directly from C).

Technical debt accumulation

Sometimes a problem arises because we simply cannot predict the future. In 1981, the “Internet” was enough for each and everyone - the first widely used version of the IPv4 protocol was described, using 32-bit addresses that limit the address space of 4,294,967,296 to possible unique addresses.

4.3 billion IPv4 addresses looked more than enough for ARPANet. IPv6 appeared in 1998 (described in RFC2460 ), but the protocol did not gain popularity. It took more than ten years for the problem of a limited number of addresses to be noticed. And then it became clear that the giant base of the developed and installed IPv4 software and hardware requires maintaining IPv6 backward compatibility with IPv4.

“Suddenly” we found out that IPv6 was developed without full compatibility with the previous version - a node with support for only IPv6 cannot connect to a node that works only over IPv4. The transition from IPv4 to IPv6 required a “two-stack” phase, during which the host computer would interact with both protocol stacks simultaneously, using the IPv6 protocol stack to communicate with other IPv6 host computers, and the IPv4 protocol stack to communicate with other IPv4 host computers .

Some switches, routers, and security devices also proved incompatible with IPv6. Thus, the process of transition to IPv6 has encountered many problems, which are proposed to be solved in different ways . None of the existing solutions can be called ideal, but each of them will find its application.

Software Backward Compatibility Philosophy

When I thought about whether it is necessary to maintain compatibility in the new version ( c )

In software, backward compatibility, as a rule, implies a strong increase in the size of files and the entire application, but this is not the most important thing. Backward compatibility usually requires historical baggage, which in interpreted languages ​​often leads to noticeable performance losses.

With backward compatibility, the codebase is inflated, the application architecture becomes complicated, and the application upgrade becomes difficult. There is a desire to reject the old and write a compact, lightweight code that uses the most modern developments.

For example, the new version of Skype can no longer establish voice and video connections with versions under Windows XP. And, of course, some users want to ignore the new release, preferring to stay on the old, but so familiar.

Yes, backward compatibility today is considered one of the most important conditions in the development of software products. It allows users to be the least painless - and therefore comfortable - to switch to new products. Manufacturers of game consoles, for example, it is important to ensure the backward compatibility of new games with old gadgets in order to maximize the audience of potential buyers. But at the same time, it is more difficult for developers to implement a new level of realistic graphics and physics, which, ironically, can reduce the attractiveness of the system for gamers.

We ourselves periodically face similar issues. When writing the Hotbox data storage cloud solution, you could completely create everything from scratch or use existing practices in Mail and Mail.Ru Cloud. Writing from scratch allows you to get rid of all the accumulated technical debt, but this is a long time. The disadvantage of using current developments is that we remain in Perl, for which it is difficult to find new developers due to its not very high popularity. But the advantages of this solution significantly outweigh: in this language we have a great expertise and tools that have been developed over the years. Since it was critical to release the product on time, we decided to stop using Perl.

The result is a product that currently suits us completely. In this case, “backward compatibility” went beyond the limits of one service only - we made compatibility not only with the groundwork in other projects, but also with our own experience. Awareness of this fact leads to a simple thought: not always a new language, a new version of the program or a new gadget is a universal solution of the task set before you.