When should you break backwards compatibility?

Question

I hate capricious projects that change at the drop of a hat.

I hate projects which are overly complex trying to maintain backwards compatibility.

• Where is the balance?
• When maintaining a project, what should one take into account when deciding to break backwards compatibility or not?
• How much effort should one put into conversion utilities and advance notice?

Followup:

A lot of great answers, thanks! Still, the balance question seems unattended. Some projects might stall because they can't add new features and maintain backwards compatibility, but they don't have the resources to provide a long upgrade cycle (ie, depreciate it for two releases, then make the change) or they may not be able to make utilities to convert.

Some answers intimate that there's an implicit promise between maintainer and user not to break backwards compatibility without providing a relatively easy upgrade path with a lot of notice.

• Is it ever ok to break this promise, or should a project hold off on new features until it has the resources to provide an easy path?

Answer 1

It depends on your users.

Some users need the backwards compatibility. And you need a lot of effort to convince them to upgrade. In that case you need to negotiate. Give them an painless upgrade tool. Maybe some features from their wishlist. But in the end you will always loose some of them.

Answer 2

A couple comments/thoughts:

• provide maintenance/support for only the current version and N prior versions. Publish this information widely.
• Provide external tools for conversions/upgrades to keep it out of product

Answer 3

At a minimum, you should keep features around, but marked deprecated for a release cycle or two. Gives you user base time to catch up with the changes, and an smooth migration path (because they can run the old and the new code at against the same installation of your tool).

Clear documentation of the changes, examples of how to migrate, tools to support data-conversion, an explicit schedule for how long they can rely on the old behavior, are all good to have, too.

---

Adam Davis asks in the comments about urgent situations:

Well, I would not recommend keeping gaping security holes around and enabled. But depending on who your users are, and what they are doing, you might still want to make them available. Adding a new switch, gives you a chance to warn them exactly what they are getting into.

Answer 4

Even though we developers are usually technical oriented poeple, the balance in this case should be in your accounting: How much does it pay, how much does it cost?

If it costs you nothing (or very little), I would always recommend to maintain backwards compatibility. If it becomes more difficult, you need to estimate how much more you would have to spend on it (mostly working hours) and compare that with an estimation of how many customers you would loose or gain by not providing/providing compatibility with older versions.

Usually the new users do not care for older versions of your software, so in most cases the number here would be 0. It comes down to your existing user base, how likely they are to switch to a competing product.

I would recommend two things:

1. Take a small survey of your users (or e representative sample) and see how important backwards compatibility is for them
2. If you want to phase out a specific functionality, do it in two stages: in the next version replace it with the new functionality, but keep the old one for compatibility. In the second next version, drop the old functionality completely. That way the vast majority of your users will have gotten used to the new way and not even look for the old functionality.

Regarding your followup:

I wouldn't say there is an implicit promise. I would call it an implicit expectation by the user. You need to be aware that most users will have this expectation. I think that its ok not to meet that expectation, if it would carry too much problems for you.

The problem with your original question is that the decision needs to be made on a case by case base. It depends a lot on your users and the relationship you have with them. Those are non technical factors, so a technical answer is not possible IMO.

Answer 5

My opinions (perhaps a little controversial)

• If you break backwards compatibility, you have to provide conversion/migration utilities that work and are easy to use. Otherwise you're betraying your clients.
• Given that the conversion utilities are provided, breaking backwards compatibility is no problem. Do it, when living with old decisions gets annoying to you.

The project should always hold off on new features until it has the resources to provide an easy migration path. Less features are better than broken compatibility.

Answer 6

Breaking changes are painful in the short term, since customers must monitor your changes and implement changes in their own code and practices. Backwards compatibility is painful in the long term, because your ability to implement new features will grind slowly to a halt.

Each way has its advantages and disadvantages.

Answer 7

It's a simple customer demand. Do you have customers that absolutely require backward compatibility? How much do you make from each customer? How much is backward compatibility costing you? When you're down to so few customers creating revenue and so much cost in maintenance, it's time to fire the customers.

Conversion utilities depend entirely on the customers that require conversion. Work it out like this.

+---------------------+--------------+
| Old Bad Code        | (some cost)  |
+---------------------+--------------+
| Replace Old Bad Code| (some cost)  |
+---------------------+--------------+
| Make Conversion Tool| (some cost)  |
+---------------------+--------------+
| Savings from better |              |
| code                | revenue      |
+=====================+==============+
| Bottom Line         | return       |
+---------------------+--------------+

---

Edit.

Backward compatibility of changes is not an implicit promise. It's a specific marketing strategy. Some folks think it's important. But it's not implicit -- either you promised it or you didn't. If you didn't promise backward compatible, then... you didn't promise backward compatible.

If the feature you are going to break is central or popular or important in some way, you have to fork your project into two incompatible versions. If you're breaking something central, it says the old design was not appropriate for the new use cases and you're starting again.

if the feature you are going to break is peripheral, hardly used or unimportant, just increase the major version number and move on. That's what major version numbers are for -- compatibility.

The only users who might care are those for whom your soon-to-be-broken feature is somehow absolutely central. So, the feature is not important to your product, but central to them. This conflict means they shouldn't have been using your product in the first place.

Preserving backward compatibility for folks who are failing to use your product as you intended isn't an implicit promise.

Answer 8

You should be concerned about backwards compatibility when

1. It locks existing customers out of old data
2. It requires existing customers to retrain to use the new software.
3. Evaluate the impact of lack of backwards compatibility on your ability to support both old and new customers.

In short there is no simple answer other than like anything with your software development process you to evaluate changes in light of it's impact.

Answer 9

Break backwards compatibility whenever the project gets too messy, and time or money are wasted.

Prepare well and plan a long phase of transition. There are good examples from the industry where it is or was planned well:

• In Python, version 3.0 breaks backwards compatibility. But the current version 2.6 already integrates Python 3.0 features to ease the transition, while keeping old features. People are expected to start using the new features so they can easily move to version 3.0 once 2.6 will not be supported anymore.

• Apple's Intel machines broke backwards compatibility in that they wouldn't run the old binaries written for PowerPC machines. Before the transition, Apple worked hard behind the scenes, writing converters and rewriting their software so that people could run their software when the Intel machines came out.

Answer 10

I doubt there is one single answer, except possibly in the form of a long equation. What will break? How much of it? Is the conversion easy? Is backwards compatibility easy? What will you gain with the new version? Are you fixing an exploit, adding or removing a feature, tweaking for consistency? How will your community react? Who is your community? Will this need to happen eventually?

There are a lot of variables. If you think there's a simple answer, look at the controversy around the IE8 rendering engine and the solutions they tried.