Hi all,
We’re adding a new tool to Bubble for managing how we release new features and evolve the way Bubble works over time.
One of the principles we follow when making changes to Bubble is to avoid making changes that would break an existing app in situations where a user might reasonably have relied on the old behavior for their app to work. In situations where a new release does break existing behavior, we generally consider it a bug and we either revert or fix it.
Although we feel this approach is necessary for Bubble to be a stable platform for development, the unfortunate consequence of this is that there are a number of things about Bubble that we wish we had built differently, but that we feel we can’t change without risking disruption to existing applications.
Previously, in situations where we really thought we should change something, we’ve worked around this by doing things such as tagging new elements or new apps with a behind-the-scenes flag indicating it should work a new way, then exposing a checkbox or option to existing users to let them opt in to the new behavior on a case-by-case basis.
While this approach has gotten us pretty far, we’re getting increasingly frustrated with it, especially given some big changes we’d like to make around how workflows function in cases where multiple users are modifying the same data. The ad-hoc patch approach leads to a bloated, ugly editor interface (lots of extra checkboxes and options), user confusion, and larger javascript files leading to slower page loads (since we have to send the code for all the variations in behavior to all apps).
So, we’re rolling out a new approach to deal with releasing potentially backwards-incompatible changes to Bubble. We’ve implemented a Bubble version numbering system, where changes are assigned a number, and app owners can upgrade their app to the latest version, or roll back to a previous one. We’ve added a new tab to the editor under “Settings” called “Versions”, where you can see which Bubble version your app is on (unless you created this app after this announcement, it will be on the “original” version), and upgrade or roll back.
The flow for rolling out a new breaking change works like this:
-
The new Bubble version will appear in the Settings -> Versions panel, with a link to a detailed description of the difference between old and new behavior (which will be posted as an announcement on the forum)
-
When you’re ready, you can upgrade to the new Bubble version. This will only affect the Development copy of your app; the Live copy will remain on the Bubble version of your last deployment
-
On the Development version of your app, you can test the upgrade, and make any changes to your application necessary for it to work with the new version.
-
Once you are happy with it, you can deploy to the Live version to take advantage of the improvements
-
If you temporarily need to go back to the old version – for instance, if you haven’t finished testing the new Bubble version, but something comes up and you need to do an urgent deploy to Live – you can use the Versions tab to roll back to the old version. (The option to revert will disappear after a week on the new version.) Also, reverting your entire app to how it was at a previous point in time will change the Bubble version to whatever it was at that point in time, so your app will stay consistent
We are releasing a new version of Bubble now, so you can see how this works with a real example. The new version is described here: Changes to Date Manipulation Functions
This new system is only for backwards-incompatible changes. New features and bug fixes will still be deployed as we’ve been doing so far: your app will get them instantly without having to make a change on your end.
We plan to use the new system judiciously, because each time we introduce a new version, it creates work for everyone: you have to read the update, figure out if it applies to your app or not, upgrade your app, and potentially make changes if it does break something. We’d like everyone actively developing on Bubble to keep their apps current with the latest version, and the best way for us to encourage that is to release new changes only when they add a lot of value and are a clear improvement on the old behavior.
Although we’d like everyone to stay up-to-date, at this time we have no plans to end support for old versions. We will probably eventually set up an end-of-life policy for very old versions, but we will give plenty of advanced warning before rolling out such a policy.
That said, we do intend to encourage people to upgrade regularly. If we release code that introduces a new bug that affects apps on an older Bubble version, we will fix that bug. Likewise, we will try to address bugs introduced by external changes such as new browser releases where possible, though we will prioritize addressing them relative to the latest version. However, if a bug existed prior to us releasing a new version, and that bug does not affect users on the new version, we will not fix the bug, and instead ask you to upgrade your app. Finally, even for bugs that we do support, we might first check with you to see if you’re willing to upgrade to the latest version, since we’d prefer to spend our development efforts improving the latest version of Bubble.
Given that, it’s important to us that you let us know if we release a version that you feel you absolutely can’t upgrade to. Our intent is to never take away capabilities: if there’s a way of doing something on the old version, there should be a way of doing it with the new version. But people use Bubble in all kinds of creative ways, and it’s possible for us to miss something. If that ever happens, and you find yourself stuck, please let us know, and we’ll make sure to build an upgrade path for you.
Anyway, again, check out our announcement about our first new Bubble version: Changes to Date Manipulation Functions
