It’s a little confusing, honestly. The way it works is this:
- For our shared hosting plans, all apps run on the same infrastructure (which is how we keep the prices affordable). We don’t currently have the ability to run multiple versions of the Bubble codebase at the same time on this infrastructure – we have to update all our main cluster applications in one go.
- For dedicated hosting, because it’s separate infrastructure, we can update a dedicated installation at its own pace, and dedicated users have a button in the editor they can press that puts the latest Bubble code on their box
We generally release code multiple times per day. For 99% of the releases, we are either fixing bugs or adding new features. We keep the behavior of existing features (apart from bugs) exactly the same, to avoid breaking apps that depend on that behavior. However, occasionally we decide that an existing behavior is really bad, and it’s worth asking people to change their apps in order to get a better behavior. That’s what the Settings -> Versions tab of the editor is about: it’s a way for app owners to say “Hey, I’m ready to opt-in to the new behavior”. This has nothing to do with releasing new Bubble code to your app: it just changes the way the current code behaves.
Now, sometimes we mess up and release a bug that breaks existing behavior unintentionally and causes app downtime. We try hard not to do that, but software development is hard and sometimes we screw up. When that happens, we revert the change, and we (usually) write an automated test to prevent that particular failure or class of failure from happening again. This automated test suite runs every time we deploy new code, and as we add more and more tests, it makes it harder and harder for us to accidentally break things.
Dedicated users are mostly protected from those mistakes, because we don’t update the version that dedicated users can deploy until it’s been 4 hours since our last deploy (ie, until our deployment seems stable). So if we do something really bad, we generally fix it before dedicated users have an option to get that version of the code. (Sometimes subtler issues do slip through).
We’d like to find a way of offering something similar to our main cluster users, because we know how important uptime and reliability are for everyone. That said, there are hard technical challenges with doing that, so right now we don’t have immediate plans to build something, though it’s something we are considering.