A few days ago, my colleagues at Nelio and I were discussing the future of our plugin Nelio A/B Testing and its upcoming features and improvements. As an A/B testing platform, the plugin requires continuous updates to keep up with the new versions of WordPress and make sure everything works as it should. Keep in mind that it is the first plugin we ever launched for WordPress, at the end of 2013, and it has been in continuous evolution since then.
The arrival of Gutenberg in WordPress opened new possibilities for split testing. And this raised an interesting question: should we make an incremental improvement of our product or would it be better to start from scratch and launch something completely new that takes full advantage of WordPress blocks?
We have not yet decided which way to go, but I thought it would be interesting to discuss what the problems of launching a new version without backward compatibility is and how we can mitigate or eliminate them.
So today I’ll explain two solutions to launch a new version of your service breaking the compatibility with previous versions in a way such that your customers won’t suffer this decision.
A Note on Backward Compatibility
As Chris Lema said some time ago in his blog, “backward compatibility is one strongly held and embraced by the WordPress project. (…) [It] is a value not just for developers. It’s a value for end users. And [if it’s broken], it’s the end user that will end up with the message saying their site no longer works.”
So what exactly does it mean to break backward compatibility? How can we break it? Here are a few examples:
- Changing the API with which our plugin can be extended (functions, hooks, etc).
- Modifying the structure of the database.
- Changing the API of our cloud (if our plugin uses one).
- Moving to a new business model and, therefore, shifting to a new paradigm of updates, features, etc.
Consider, for example, our A/B Testing service. Roughly, this is how it works:
- The user can create A/B tests on their website. In essence, an A/B test consists of the page you want to test, one or more variants of that page, and the conversion goals we’re trying to improve. All this info is stored in WordPress.
- A cloud component is responsible for tracking visits to a website that uses Nelio A/B Testing. Similar to what Google Analytics does, this component collects the information, processes it, and generates a summary of digested results. And, exactly as GA does, this data is sent using a tracking script.
- Finally, there’s a view in the plugin that connects to this cloud through an API. The view pulls the digested results and shows some stats and graphics to the user.
A plugin like Nelio A/B Testing can change in many ways and, if we are not careful, one of these changes might result in a “broken plugin”. For example, let’s assume we want/have to update the API of our cloud. In this case, we’re forced to update our plugin as well, since the tracking script and the results view depend on that API. Therefore, a new API requires a new plugin. But here comes the problem: this new API also means our users are now forced to upgrade, as previous versions of our plugin won’t be able to communicate with the new API.
Now put on your users’ shoes: a plugin that worked smoothly and flawlessly, is no longer working because of an update you made in your cloud. Not cool. Not cool at all
Possible Solutions
Breaking backward compatibility is not a trivial issue. It’s something that requires careful consideration. And, in any case, the most important thing is to opt for a solution that does not leave your current users with a non-working plugin. Especially to those who are paying you for your service.
If we are sure that what suits us best as a freelancer or as a company, for whatever reason, is start from scratch with a completely new version of our product and get rid of backward compatibility, there are two solutions. With them, we will be able to make a clean slate while making sure our users will still be able to use what they had before.
Nelio A/B Testing
Native Tests for WordPress
Use your WordPress page editor to create variants and run powerful tests with just a few clicks. No coding skills required.
Launch a New Product (opt-in)
The first solution we have to launch a version that’s not backward compatible is not to do so. Instead, launch a new product!!
This guarantees that current users have an operating plugin that works as usual. In fact, they will never be able to upgrade to a version that “breaks things”, simply because that new version will never exist; you’re launching a totally new plugin and putting your efforts in updating this new plugin, which means they’re “freezed in the past”.
This, of course, raises some serious problems that need to be addressed:
- The users that we already have will not know that there is a new version of our product, unless we tell them so. This means we need to promote our “new plugin/service” in the old one, which looks odd… but works fine.
- Launching a new product is very difficult. All the effort you made with the previous product (creating a brand for it, positioning it, getting reviews, active installations…) are lost and you’re forced to start from scratch.
This is an opt-in solution: we launch a new product and invite you to stop using the old and get the new product. This is what WordPress did (sort of) several months ago when they released Gutenberg as a plugin: you were the one who decided if you wanted to use Gutenberg in your site by installing the plugin on your website.
Launch an Update that Breaks Backward Compatibility (opt-out)
Another option is the inverse approach, or the opt-out solution: release an update of your product that breaks backward compatibility and, in parallel, launch a new product with the old version. In this way, even if the new version isn’t backwards compatible, we offer our users an alternative so that everything works as they’re used to.
This method solves the two problems we raised in the previous solution. On the one hand, all users will know from the very first day that there’s a new version of our product/service, and they can see and try out what’s new.
On the other hand (and perhaps more important), we continue to profit from all the work we had done so far, since we simply launched a new version of a well-established product. You’ll keep the brand, the reviews, the stats… nothing will change, as you’re not starting from scratch.
As you can imagine, this is the opt-out solution: whenever a user updates their plugin, they’ll see the new version (even if they don’t like the fact that it breaks backward compatibility). But you’re also giving them the opportunity to switch back to the old version by installing a new product. This is what WordPress did last December when it introduced the block editor in its latest update and offered users the possibility of using the old editor by installing the Classic Editor plugin .
In Summary
Breaking backward compatibility is not trivial, since it can have big implications for your users. In general, we would not recommend doing it. But sometimes it’s the only option you have.
If you have to do so, I recommend you implement one of the two solutions we’ve seen today. With them, you make sure your users will have a backup plan so that “everything works as it used to” and nobody will complain about “things being broken”. Of course, as a counterpart, you’ll have to maintain two products (even assuming that the “old” version happens to have minimal maintenance), but this is a topic for another post.
Now tell me, have you ever faced a problem like this? How did you solve it? What would you do?
Featured image by Dietmar Becker in Unsplash.
Leave a Reply