Important new tab in editor

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


Thanks for such a well thought out implementation!

We’re especially looking forward to this:


I think this makes a lot of sense.

Can you give some examples of functionalties that an app might have that you might break if you were to clean up the code on your end?

Any special implications for users on dedicated plans?

Well, for example, right now if two workflows run by two different users both try to increment a thing’s number field by one, and they run at the same time, the field may go up by 1: one user’s changes might completely overwrite the other’s. We very much want to change this so that the workflows always run one at a time: it would make programming in Bubble a lot simpler if you could rely on the number always going up by 2 each time. However, this is a big change to how things work today, and there might be corner-cases where a user is relying on the current behavior: for instance, a game where users are racing to be first to click a value, where you want it to change as fast as you can and are fine with users overwriting each other’s answers. So we wouldn’t want to just change it without letting users test the change on their own apps.

Not really. Dedicated clusters will still upgrade their boxes the same way as before. When we release a new Bubble version with this new feature, it’s a two step process to get it: first you upgrade your dedicated cluster like always, and then you can go through and update each app on that cluster using the process described above. Upgrading the cluster won’t automatically upgrade your apps – you can do them one-by-one if you have multiple apps on the same cluster.

We’re actually working on something to make the code upgrade process nicer for dedicated users: we’re going to let you create a copy of your app on the main Bubble cluster, so you can test your app on the latest version of the Bubble code before you upgrade your dedicated cluster. We’ll likely release this sometime in the next two weeks.


Nice job @Bubble team.

I’m guessing this makes my idea deprecated :slight_smile:

Again, thank you for this great functionality and the detailed description.

1 Like

This is amazing.

Will certain workflows/actions have priority, or is it a linear, first-come-first-serve basis for all?


What am i missing here? I can’t find the Version tab anywhere. Help please?

Did you refresh the editor?

Thanks! A refresh helped.

Any news on how to change my app back from a template? Seems like it is stuck in template mode. :slight_smile:

Thank you all so much! I’m sure this has been an insane amount of work. Less downtime + smoother deploys = game changer for production grade apps.

1 Like

Same here. Did you need to upgrade to see the ‘version’ tab?

I Justin had to refresh. I pay for my plan though. Not sure if that makes a difference.

Reading some threads, I realize some users don’t refresh their editor often. In general you should do this once a day, that’s the only way to get the latest version, and as Bubble saves everything continuously, it’s quite seamless to do so.

1 Like

Having worked with software developers for a long time, I can fully relate to this. I’m pleased that you are taking an even braver approach to making significant improvements. If you need to be careful, and develop for legacy, current and future versions, you will end up dividing your resources thin, frustration sets in, and nothing major gets done.

Personally, I hope this new approach brings significant improvements to loading speed of Bubble apps eventually, like you suggested.

1 Like

@josh, are there any special consideration for parent apps and sub apps?

Specifically, do we need to also go into every push in every sub application and manually approve the update? Or will updating on the parent application push to sub applications?

From what I see, we need to manually push in each sub application. Or is this overridden after we do our next push to live on the parent app?

Based on my understanding, I would be keen on a checkbox option on the parent app (defaulted to unchecked) that lets me push to sub applications at the same time I push the Bubble Engine update for the parent.