Backwards compatibility

From Jonathan Gardner's Tech Wiki
Jump to: navigation, search

You want to change your software, and it's going to break people who use your software.

Listen closely: DON'T DO IT!!!

How can you make a "backwards incompatible" change, then?

Here's how.

Version 0: The old version that does A.

Version 1: Does A and B together. It translates A into the context of B as best as possible, using good defaults. At this point, A is deprecated and clients are warned to upgrade.

Version 2: No longer does A. Only launch this when everyone has migrated to B.

There is no case that I ever encountered in any framework or environment where this was not possible.

If you have one, I'd like to hear about it. I can probably come up with a way to make the change without breaking backwards compatibility.

NOTE: The Python community is extremely good at this. If you upgrade from version X.A to X.B, you are guaranteed your X.A code will run the way you expect it to. They only drop functionality in upgrades from X.A to Y.0. This is the story of Python 3. They wanted to make some backwards incompatible changes without breaking all of Python, so they provided an intermediate version that supports both. It's up to use Python 2 developers to stop using the Python 2 features that break Python 3. When we've all done that, Python 2 will be retired.